“Shadow fart” - ehhhhhhh, no

What no? I think you just proved their point 🤣

Feel free to just use React on the frontend if you’re more familiar with it, but make sure you couple it with Redux. Then when the time comes you want to bring some Rust into the frontend, you can do so by writing your Redux reducers in Rust.

PS.: The blog post mentions using fp-bindgen for WASM bindings, but nowadays you’re probably better off using wasm-bindgen.

Sorry, but this mindset is hurting both Linux and security in general.

The reason we are seeing a lot of security vulnerabilities is because prior to about 10 years ago security wasn’t considered that important.

This is frankly quite obviously false. Microsoft started taking security more seriously around the release of Windows 2000. Are you saying the Linux kernel developers took another 15 years to realize security is important?

Security research shows that new code is more prone to common vulnerabilities than old code is. While old code may have been designed with weak (or no) security considerations, those are well-mitigated by now. On the contrary, new code still regularly contains exploitable memory safety issues that slip by review.

What we need is skilled programmers who understand security.

We have skilled programmers who understand security. Those also understand that we need more than that.

Continuing to use C doesn’t merely require skilled programmers, it requires programmers that never make any mistake ever. That’s an infeasible standard for any human to uphold, hence why C is considered a risk.

I agree the Linux kernel is just fine. But that’s only because despite the security risks of C, there’s no viable alternative kernel.

But development doesn’t stand still, so either Linux catches up, or gets replaced when a viable alternative arrives. Thankfully Linus sees the problem, so they’re working to make the kernel viable a while longer, but I also agree with the person you replied to that this work could definitely use a bit more help.

Yes, it has a few APIs of its own. I merely think they are negligible in this discussion because they only provide a minimal superset over Node.js’s own APIs and are also very minimal compared to what Deno provides.

I’ve updated my post to mention “noteworthy” APIs.

You’re ignoring the fact that for many projects it does work.

It only needs to be perfect if you want to run 100% Node.js software unaltered. While that may be a lofty goal, it’s also an infeasible one.

That doesn’t mean imperfect support is futile though. By your logic, Bun has no right to exist because it only supports Node.js APIs and doesn’t have noteworthy APIs of its own, and they’re not perfect either. Yet they seem to be at least as successful as Deno is.

Or for an example in a different domain: Your argument would state that a project like WINE shouldn’t exist because it doesn’t have perfect compatibility with Windows, and it disincentivizes development of Linux games. Yet it is largely thanks to WINE that Valve has been able to make the Steam Deck and that Linux gaming is finally taking off.

I think what your argument fails to take into account is that you need a significant amount of users to make any impact on the market. And many users have legacy requirements that they can’t throw out overnight, so you have to support those legacy environments. And even with imperfect legacy support you can support your users, especially if the users are willing to make a few changes here or there. But if you have no legacy support, you also get no users except those that have niche greenfield requirements.

So instead of trying to replace NodeJS or offering an upgrade path for existing Node projects, incentivize formation of ecosystem around Deno

They are incentivizing their own ecosystem. That’s what Jsr.io is all about. But the world isn’t black and white. They can do more than one thing.

I dunno, I still see a blog post. Which is hosted in their own issue tracker, which is of course odd, but also the point.

Maybe it went down for a bit?

So I do consider myself to be a true full-stack developer, since I do have 5+ years of experience working on each of server-side, CLI, desktop applications, and mobile applications and 10+ years on the web frontend. Then again, I’m 40 and I feel too old to get offended over that shit. I also agree the term “full-stack” is diluted as hell, so I don’t even call myself that anymore.

Now get off my lawn :p

Didn’t expect my message to show up here ☺️ If you’re curious about the slides, I posted them as PDF in the general channel on our discord: https://biomejs.dev/chat

Or you can view them here: https://www.canva.com/design/DAGYn133HV8/TEA45MC20creMTPaM9O5sA/edit

I would love to see Go, Rust, Swift and Kotlin added to this. Anyone willing to take a shot?

As someone still gleefully using an original Steam Controller with their Steam Deck, I can’t welcome this enough!

Only reason I can think of why I wouldn’t buy this is because I frankly don’t need a new controller. The first one is still good enough for me. But I know it’s no longer produced, so it may be a good buy for others. And I too would prefer to have well-supported options if mine ever dies.

Good news: if you’re writing #Rust and only using basic features of the language, you’re doing it right.

People who use the advanced stuff either have unique, interesting challenges, or they’re over-engineering. Since the former are overrepresented in the blogosphere, you’re probably comparing yourself to them. But just because their problems are interesting doesn’t mean yours are not! Nor does it mean you have to use the same solutions.

If you can solve interesting problems (it sounds like you can!) and keep the code simple, more power to you!

Opinionated summary: Developers saw REST, picked the good parts and ignored the rest (no pun intended). They still called it REST, for lack of a better word, even though things like HATEOAS were overkill for most of the applications.

I use EndeavourOS and really enjoy it. It’s effectively Arch but without the fuss. You get a GUI with just a few steps to set it up and you’re good to go. I tend to upgrade once a week, while checking the forums to see nothing too bad broke. That’s basically the maintenance I have.

When I do a new install on a new device, I just clone a repo I keep with the most important config files. Then I copy them to where they belong. There’s really not much more to it.

Boa is a remarkably well-developed JS runtime written in Rust. Nice API, and well sandboxed. We’re considering adopting it for Biome as well.

Unfortunately true. I have no solution for the American people. Merely sharing my thoughts to hopefully limit the impact on the democracies that remain.

Using smart pointers doesn’t eliminate the memory safety issue, it merely addresses one aspect of it. Even with smart pointers, nothing is preventing you from passing references and using them after they’re freed.

Would you have a link to that? I know there are many third-party garbage collectors for Rust, but if there’s something semi-official being proposed or prototyped I’d be most curious :)

Cool, that was an informative read!

If we were willing to leak memory, then we could write […] Box::leak(Box::new(0))

In this example, you could have just made a constant with value 0 and returned a reference to that. It would also have a 'static lifetime and there would be no leaking.

Why does nobody seem to be talking about this?

My guess is that the overlap in use cases between Rust and C# isn’t very large. Many places where Rust is making inroads (kernel and low-level libraries) are places where C# would be automatically disqualified because of the requirements for a runtime and garbage collection.

I think that’s very team/project dependent. I’ve seen it done before indeed, but I’ve never been on a team where it was considered idiomatic.