nous

Syntax is in a large part what people are used to. Which is trivial to change by just using the thing for a while and getting used to the different syntax. But syntax is only part of a language. The tooling, documentation, error messages, and general feed back are all IMO much nicer in rust than C++. It is also easier to people new to programming or used to other languages to get into than C++ is, even including the syntax into that.

C++ was one of the first languages I learnt - and now after not using it for years I cannot stand its syntax.

From their blog post:

Finally, subjectively, C++ isn’t drawing in the crowds. We have never had a lot of C++ contributors. Over the 11 years fish used C++, only 17 people have at least 10 commits to the C++ code. We also don’t know a lot of people who would love to work on a C++ codebase in their free time.

Hard to tank when you don't have many to begin with. Rust is far nicer to new users to contribute to then old C++ code. Which can be seen in their github - in the last 24 months 16 people have contributed more then 10 commits. Which is during the conversion period - I dont expect that many of those to be C++ contributions. So rust does not seem to have hurt their contributions at all and in fact looks to have helped.

First thing I typically do when that happens is update my system and reboot. This is useful for ensuring everything is in a known consistent state and there is no weird runtime issues that happened since you last booted. And it is always good to upgrade before you reboot to ensure you are booting the latest kernel and drivers.

If that does not help then I would start by closing down steam completely (ensure it is not running in the systray at all). Then launch steam though a terminal and start the game as you normally would. You will hopefully see some logs for the game in the terminal. Though it is very game dependent as to if that will be useful at all. If not I would look online to see if the game logs anything to any other file as some games tend to do their own logging or have a flag you can enable.

If the game gives you some logs and hopefully an error message you can then see if it is useful to you and if not try googling for that error and the game name. I find this tends to dig up more specific help for games then general searches for terms like wont start or crashes though sometimes those general terms can find a solution as well.

Note: if you try to launch steam in the terminal and it is already running you wont get any logs at all from it - it basically just forwards things to the main instance or quits as it does not need to do anything. Only the first instance you start will give you and useful logs.

Closest thing to an enum you can get with go. Sadly. No clue why they omitted them.

On quite a few terminals, alacritty is one, you can hold SHIFT while dragging to select things on the screen to copy from. This suppresses sending mouse events so works when you have editors, tmux or other things that can interpret mouse clicks. It does mean that it is just copying chars from the terminal so ends up copying everything on the screen. Unlike the copying baked into things like tmux of editors.

I don't understand the RT/LT for mouse buttons. Such a long movement to get to a click just feels unnatural to me. When the track pad has a press to click why not use that instead? At least for the primary button.

For Windows, software compatibility is actually excellent: a lot of 32-bit Windows 95 software still runs perfectly on Windows 11 64 almost 30 years later. Nothing remotely close exists for Linux.

I would need to see the numbers on that. A lot of software written back then assumed full admin access at all points and I bet there is quite a lot that actually wont run on a modern system anymore.

What's worse is that software compiled for the current version of Linux X will not necessarily work for the current version of Linux Y. Linux distros insist that all the software must be compiled for their current releases or provided as source code.

This is no longer true with things like flatpak. The kernel itself has even more legendary backwards compatibility promises than even windows does. It is mostly the userspace in Linux that is a mess in that regard - but flatpak, and containers in general, fixes that.

However, savvy readers of this article will notice that Linux offers flatpaks, snaps, and AppImages. I'm not going to write an insightful treatise on their shortcomings, so I'll just say it bluntly: these are all lightweight virtual machines.

They are not virtual machines - they do what most Windows apps really do: ship with all the library code they need to run. There is no visualizing the kernel at all - that is closer to what Windows compatibility layer does (not quite, more emulation of kernel APIs like wine - but closer than what flatpak is doing).

It's crazy to think that they solve software incompatibility in Linux, they just work around it by making the user allocate and run gobs of binary code, unnecessarily taxing their storage, CPU and RAM. What's worse, you can just as easily run them under Windows' WSL. So what's the point of having Linux installed on your computer in the first place?

This coming from an OS that ships a whole another OS with its OS just to get a decent terminal?

Regressions are introduced all the time because Linux developers spend very little to no time checking that their code changes don't cause regressions or breakages outside of the problems they're trying to fix or features they're implementing.

Remember that time a windows application update crash half the world?

Linux hasn't seen any AAA titles for many years now,

Huh? Most Windows games run just about flawlessly on Linux now or with minor tweaks. The only real big problems here are ones with kernel level anticheat software. See the above comment about that kernel level access to arbitrary programs...

Countless software tiles in Linux have a huge number of bugs and missing features

... Really? It is software. It has bugs. All software does. Even that which runs under windows.

And once you start looking for people to answer your questions, you'll see the real face of the Linux community.

I have always found the Linux community to be far more welcoming than any Windows community I saw...

None of those arguments are good. Half apply to Windows just as much as Linux. And others are woefully outdated that I had to double check the article was not decades old.

Linux has been ready for the desktop for a long time now. Maybe not every system and every usecase but far more than not. Most users could switch over to it if they wanted to but they don't not because of a fault of Linux but because Windows is also good enough for their usecase and they have no reason to switch. And their system already came with windows and that is what they know.

Gaming has come a long way in the past few years to a point where quite a few gamers are starting to switch. And if you look at devices like the steam deck the default option that works well enough is what windows out - or else you would have seen most people installing windows on the decks. People do, but only a tiny fraction of them.

Far more I feel are actually migrating to Linux on their main systems instead. Largely in part because of what Windows are doing to their latest version - it is all give people a reason to move off the defaults as they are trashing them with the latest releases. Have a slightly old computer? Need to buy a new one or else you cannot upgrade. And if you do upgrade you get ads, recording of everything you do and so much more shit that people are actively getting fed up over.

I generally think mocking should be the last resort tool you reach for when testing - not just databases but anything. Test with real things where you can and you build in much fewer assumptions about their behavior. Though I also dislike testing against things that the tests have no control over. Which the author does not go into any detail on at all and is the big pit fall that makes testing against real things a huge pain.

If possible an in process or at least an temporary in memory substitute should be used over the real thing. For instance if you are using sqlite or (an ORM that supports it) this is trivial. Each test can have its own instance that does not interfere with other tests (which is where flaky tests tend to come from) and everything being local is fast enough for unit tests.

Lacking that fake implementations are a good bet as well. A good example of that is this goflakes3 package that acts as a in memory implementation of the s3 API in go. Again it is fast, you can spin up isolated instances in your test and it bakes in fewer assumptions about how s3 works in your tests (and if its assumptions are false they can be fixed for everyone where with mocks you have to find and fix every mock you have written).

Even things like filesystem interactions are easy to test for real on - I never understood peoples obsession with mocking out filesystem calls. If your filesystem is unreliable you have bigger problems to worry about and go fix. Isolation is the only real concern here but that is trivial to achieve by creating a temp file or directory unique to each test case. And the only change needed for your code is to be able to change the prefix for where it looks for the files/directories in question (which is often something you want to support anyway).

We really need to stop mocking out everything and picking mocks up as the first tool when you want to test something. Isolating a test to only test a single function in isolation of everything else just means you need to write more tests and that the tests don't end up testing as much as you fail to test the assumptions about interactions between your components. As long as your tests are fast and reliable there is little need to break them down into tiny component bits and mocking things they need to use.

Use real implementations if you can. Fakes if you cannot control the real implementation and mocks as a last resort.

Neither of the companies want to support Linux. Simple as that. Or else their launchers would work on Linux without needing third party ones. They don't see Linux user base as big enough to be worth the effort.

IMO it is clickbaity because it promises to compare rust and zig, but in reality it is just comparing unsafe rust and zig. IMO all it really needed to not be is the word unsafe in the title like they use everywhere else in the article. That is fundamentally my only problem with it. I do agree with your other points on knowing when a tool is good or not to use but I would have been much less likely to click on it if it mentioned unsafe in the title - I already know rusts unsafe is not the best and was expecting some arguments around the advantages of zig over safe rust -ie what most people write, not a small subset of the language.

That’s true for your application maybe, but they go on to say how one should consider whether or not their problem is going to fit well within the rules of the rust borrow checker and that needs to be talked about more (vs just assuming Rust is the safest option).

Yeah, that is why I was calling out their title as click bait. Saying Rust vs Zig will mean most people think of safe rust vs zig. But the article is about unsafe rust vs zig which is a completely different story IMO. If you need lots of unsafe zig might be better - but the title does not say that. Hence IMO it is clickbaity.

Rewrites aren’t often done outside of hobbyish projects because they’re very expensive, stop new feature development, and you really can end up with something that’s worse than what you started with (this is especially true if you’ve switched languages or frameworks).

Ok I will give you that for big projects. But this is on the other side of that. If you write two things in quick succession you will more likely still have the problems encountered in mind and be better able to navigate them the second time than if you are part of a large team that has had a lot of turn over since the project was first written. And you might make different mistakes - but the second round of mistakes is normally less impactful then the first set.

They do explain with citations why it makes more sense (i.e. you end up with something more performance) to write their VM outside of the restrictions of the borrow checker.

Oh yeah, of course this case I can see all that being true. But fundamentally they chose this problem because of that given they said:

I wanted to test this myself and see how hard unsafe Rust would be by building a project that required a substantial amount of unsafe code.

Sounds like they want to compare unsafe rust with zig. They started with that idea which from my experience is not typical of most applications so their findings are not either.

I think the claim is a bit of a stretch off the cuff.

Yeah that one might be.

Though unsafe rust overall is not a large amount of what rust code is, the author does seem to be picking the topic based on the hardest parts of rust and their title talks about all of rust which IMO is an unfair comparison. The story of zig being better than unsafe rust is interesting but only part of the whole zig vs rust debate.

Title is clickbait. They only talk about unsafe rust, which I can see zip being safer/easier than unsafe rust. But 99.9% of code I write is safe rust - which most people just call rust. Even the author calls out the vast difference to writing safe vs unsafe rust:

Overall, the experience was not great, especially compared to the joy of writing regular safe Rust.

Then I would re-write the project in Zig to see if would be easier/better.

Of course it will be. The second time you write any project it will be easier and faster as you learn a lot form the first time you write something. If zig is always the rewrite it will come off better. Almost all rewrites are better or faster, even if you are moving to a slower language - the language makes a difference to performance and ease of writing. But far more does how you write things and the data structures/algorithms you use.

Overall they seem to want to write as much unsafe as they can and are writing rust like it is C. This is not a good idea and why zig will be better suited. But you can write a VM without large amounts of unsafe if you want to and it can be performant. Unsafe can be used in small parts where performance matters and cannot be done without it (though this is not that common I find).