That said, I also acknowledge that often times I need to solve problems that can benefit from a language that embraces what I call necessary complexity, but do it in elegant ways. Whenever I need to prioritise code correctness, especially memory and concurrency safety, using a mostly functional pattern instead of OOP, but without going as extreme as say Haskell, I unquestionably choose Rust, my favourite complex language. I often work with network code that is highly concurrent, must be as correct as possible and benefits from good performance, so then again, Rust feels natural here.

On the other hand, I love coding simple indie games and for that particular case, I like a simple and performant language using an imperative, non-OOP style. In my opinion C, and in particular Odin more recently are quite a good fit. If Jonathan happens to be reading this comment, since he mentioned Golang, I would suggest him Odin as perhaps the best of both worlds between C and Golang. It has all the simplicity of Golang, but without a garbage collector, plus it is quite easy to code a game using Raylib.

It says this however:

"Expected to ship to customers in February 2025."

I wonder if a typo or if batch 2 is already gone too...

I guess immutable distros such as this one target people who don't need much customisation and mostly just need what's already there anyway.

In fact, this is what I've been doing in other distros, like Debian stable, nevertheless I have no real control of the few updates to the base system with side effects.

This is not the first immutable distro, but it comes from the people who develop my favourite desktop environment, so I'm tempted to give it a try. Especially as it looks more approachable than something like NixOS.

In my experience there are roughly three main drivers for adopting the language: 1. performance, 2. code correctness / safety (my case) and 3. tooling/ecosystem. This is what makes Rust interesting for many devs.

That said, I do agree when the author points out the relatively low adoption by companies, mentioning reasons like hiring lag and risk aversion. C/C++ have decades of market penetration and it's only natural they're still in high demand when it comes to both legacy and new software.

I use Rust for almost all my personal projects and for recreational programming, but when it comes to the "real world", I think the best way to expand its use is to find some projects which could benefit from one of the main drivers I mentioned above and port it. Obviously this takes time, even more so when talking about starting new projects in Rust.

Go's history was different, perhaps because the learning curve is lower and thus it allowed and still allows a painless transition, including onboarding junior devs. It's a chicken and egg problem, in order for Rust to be more popular in the industry you need more projects to adopt it, but for that to happen, you need it to be more popular.

> Another is that the manual brake is insufficient, but the pneumatic/air (assuming those are the same) brake should be at maximum force, but for some reason, it wasn't applied at maximum force by either the brakeman or the automatic system.

Agree and I would add a third possibility:

The delay between detection and automatic full brake application, or by the cabin driver was long enough to allow enough speed/inertia to build, beyond the threshold until which the brakes would actually make it stop.

Most people here have exactly the same view you expressed. My initial reaction was the same as well. Then, on top of it all there's the political noise where each party is now trying to take some advantage out of the situation, which isn't pretty. Besides, we both know well how things usually happen here, so it's only human to think there was some kind of gross mistake. I want to believe it wasn't the case this time, but who knows... We will have to wait and see.

Hearing some local experts, they often mention that this is physically not enough to stop a 14 ton vehicle (plus passengers) going downhill when the slope is as high as 18%. So basically even if in perfectly working condition, the bake pads or wheels would just slide down the tracks as there's not enough friction for the resulting force.

Maybe something like a rack and pinion railway or some other kind of drastic metal locking mechanism are the only realistic way to prevent catastrophic events when the cable breaks/detaches, considering the masses and slopes involved here?

Coming from the same country as you, I totally understand. However, in this particular case the maintenance seems to have been done as it was supposed to be.

The problem seems to be that the cable broke at the anchoring point underneath the cabin, already underground. This is hidden from view during a normal daily inspection, where someone goes underground and checks the whole cable during a round trip of the cabin. They check the free cable going through pulleys and a flywheel, but they can't see inside the attachment point where the cable meets the cabin. This is only done in more thorough inspections, which do not happen daily.

Now, why it broke exactly at that point is probably related to how it was installed and not so much poor quality of the cable itself. Although some manufacturing issue could also be related.

We will have to wait and see, but like you said, several innocent people are dead. Hopefully in this case it wasn't down to our culture of "it's good enough, let's move on", which indeed, unfortunately, is part of our history. The least we can do now is find the real causes and make it safer in the future.