arendjr

No sorry, we follow Prettier’s philosophy there.

Is this the rule you might be looking for? https://biomejs.dev/linter/rules/use-sorted-classes/

I’m one of the core contributors to Biome, btw, so feel free to ask questions!

Yeah, I mix them too, although I apply quite a bit of functional techniques especially at the architectural level as well. OO I use mostly for dealing with I/O and other areas where statefulness cannot be avoided.

If you’re interested, I also wrote an in-depth blog where I touch on these topics: https://arendjr.nl/blog/2024/07/post-architecture-premature-abstraction-is-the-root-of-all-evil/

Just keep in mind that inheritance is nowadays a very contested feature. Even most people still invested in object oriented programming recognise that in hindsight inheritance was mostly a mistake. The industry as a whole is also making a shift to move more towards functional programming, in which object orientation as a whole is taking more of a backseat and inheritance specifically is not even supported anymore. So yeah, take the chance to learn, but be cautious before going into any one direction too deeply.

Between Rsbuild, Farm and Mako, I wonder which one will emerge victorious. It seems Rsbuild is the most well-known at this point, but also the slowest of the three (though it could be argued at this point they're all fast enough). Farm has compatibility with Vite plugins as its ace, while Mako is supposedly the fastest of them all.

Meanwhile, Vite itself is apparently not sitting still either, investing in Rolldown to speed up and improve its own bundling. I encourage their friendly competition. It seems the main winners are the users :) (unless you bet on the wrong horse, in which case you may grumble and hope for a better pick with your next project :p)

and that burden is as far as I’ve seen being forced on those long term contributors.

This is not what is happening. The current long term contributors were asked to clarify semantics about C APIs, so the Rust maintainers could take it from there. At no point were the C maintainers asked to help maintain the Rust bindings.

I think I would put the emphasis slightly differently: I don’t feel the confusion is around the word “spawn”, but it spawns futures rather than tasks. For tasks you might indeed expect them to be picked up in the background (which is what work-stealing does), but futures only execute when polled.

I was aware that indeed the trait and lifetime bounds were an artifact of the Tokio work-stealing behavior, but Evan makes a very well-explained case for why we might want to consider stepping away from such behavior as a default in Rust. If anything, it makes me thankful the Rust team is taking a slow-and-steady approach to the whole async thing instead of just making Tokio part of the standard library as some have wished for. Hopefully this gets the consideration it deserves and we all end up with a more ergonomic solution in the end.

Of course, I’m a user too, but I don’t think Linux’s UX is that bad. It may be bad in some areas, but it’s not bad across the board.

I also don’t think Linux is only for developers. It’s great for developers, but it’s also great for people with only basic needs of their computer, those that don’t need much more than a browser, an email client and maybe an office suite. The UX is totally adequate for them, as evidenced by ChromeOS.

I think where Linux lacks is mainly for the users in between, those who are not full developers or tinkerers, but do want to mess around and do so from a perspective of expectations of how things worked in the Windows world. And I won’t deny there’s a plethora of legitimate enterprise use cases for which there is no equivalent in Linux today. But those are not UX issues, those are mainly matters market support. Linux is not great there, maybe it never will be. Or if it does, it’ll take a long time.

First example that came to mind was actually Mac users who struggle with external monitors/projectors and things like screen sharing too. I agree they’re things that are so basic they should just work. Reality is often different even on other OSes.

Of course if you have a Windows home and everything works and then you try Linux and it struggles with a piece of equipment, it’s easy to blame Linux. You wouldn’t even be wrong. But you are oblivious to someone else’s experience who uses Linux exclusively and everything works for them, how many of those things wouldn’t work or work well with Windows.

Personally I’m a developer, so I care a lot about integrating parts of my development stack. A lot of those things don’t “just work” on Windows, or even Mac, so I’m happy to stick with Linux instead.

I agree with your examples and it’s certainly true there are plenty of rough edges on Linux. Then again, how many examples are there for things that should “just work” and do on Linux but don’t on Windows? There’s enough that make me not use Windows at all, because it has a subpar user experience. I even used a Macbook for a few years, mainly for work, and there were too many small things that annoyed me about it, so it too had a subpar user experience.

Seems it’s mostly a matter of perspective which issues are more important to you.