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.

This does look cool. How would it work together with Steam Input?

I don’t know about your workplace, but if at all possible I would try to find time between tasks to spend on learning. If your company doesn’t have a policy where it is clear that employees have the freedom to learn during company time, try to underestimate your own velocity even more and use the time it leaves for learning.

About 10 years ago I worked for a company where I was performing quite well. Since that meant I finished my tasks early, I could have taken on even more tasks. But I didn’t really tell our scrum master when I finished early. Instead I spent the time learning, and also refactoring code to help me become more productive. This added up, and my efficiency only increased more, until at some point I only needed one or two days to complete a week’s sprint. I didn’t waste my time, but I used it to pick up more architectural stuff on the side, while always learning on the job.

I’ll admit that when I started this route, I already had a bunch of experience under my belt, and this may not be feasible if you have managers breathing down your neck all the time. But the point is, if you play it smart you can use company time to improve yourself and they may even appreciate you for it.

If we’re looking at it from a Rust angle anyway, I think there’s a second reason that OOP often becomes messy, but less so in Rust: Unlimited interior mutability. Rust’s borrow checker may be annoying at times, but it forces you to think about ownership and prevents you from stuffing statefulness where it shouldn’t be.

You can use the regular data structures in java and run into issues with concurrency but you can also use unsafe in rust so it’s a bit of a moot point.

In Java it isn’t always clear when something crosses a thread boundary and when it doesn’t. In Rust, it is very explicit when you’re opting into using unsafe, so I think that’s a very clear distinction.

Java provides classes for thread safe programming, but the language isn’t thread safe. Just like C++ provides containers for improved memory safety, and yet the language isn’t memory safe.

The distinction lies between what’s available in the standard library, and what the language enforces.

Modern C++ does use references, which can also reference memory that is no longer available. Avoiding raw pointers isn’t enough to be memory safe.

Try browsing the list of somewhat recent #CVE rated critical, as I just did to verify. A majority of them is not related to any memory errors. Will you tell all them “just use a different programming language”?

I’m sorry, but this has been repeatedly refuted:

• Google “analysis shows two thirds of 0-day exploits detected in the wild used memory corruption vulnerabilities”. Source: https://security.googleblog.com/2024/03/secure-by-design-googles-perspective-on.html
• “Microsoft: 70 percent of all security bugs are memory safety issues” Source: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/

And yes, they are telling their engineers to use a different programming language. In fact, even the NSA is saying exactly that: https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3215760/nsa-releases-guidance-on-how-to-protect-against-software-memory-safety-issues/

It doesn’t come out today, it’s been there for a long time, and it’s standardized, proven and stable.

This seems like an extremely short-sighted red herring. C has so many gaps in its specification, because it has no problem defining things as “undefined behavior” or “implementation defined”, that the standard is essentially useless for kernel-level programming. The Linux kernel is written in C and used to only build with GCC. Now it builds with GCC and LLVM, and it relies on many non-standard compiler extensions for each. The effort to add support for LLVM took them 10 years. That’s 10 years for a migration from C to C. Ask yourself: how is that possible if the language is so well standardized?