I think many people that blindly say you cannot learn anything from vibe coding have some sweeping assumptions. It obviously depends. If you just let it do everything without even reading the code and understanding it, then yes. But the act of reading code is one of the best ways to actually learn, no matter if you read code from a human or from an LLM. I tend to learn way better by example than by reading a theoretical book.

As far as I researched, only closures could generate dangling references and therefore need memory cleanup, but only if I allowed closures to access their environment (variables and functions) by reference / mutable reference.

To avoid this and simplify both my code as well as the mental model for the users of GluonScript, as of now, closures capture their environment by cloning it immutably. There's an increased memory usage with all the copying of the environment but there are never references to something that isn't being used anymore and therefore no need for a GC. At the end of the day all values captured by closures are owned Rust values that are dropped by Rust when no longer in scope.

So this can lead to high memory usage in hot loops but it can't lead to memory leaks.

I didn't want any optimisation complexities and just focused on being able to understand my own Rust code. I was surprised by the performance I got simply by using my favourite language and as a bonus, since Rust takes care of all the ownership and lifetimes, I don't need a garbage collector. For sure, right now I'm being super conservative and rely on cloning stuff to avoid lifetime hell in stuff like closures, but the speed and memory profile is still very decent.

For anyone interested in a simple to understand tree-walking interpreter in Rust, which is heavily based in expressive enums where code is data, here's my interpreter:

https://gluonscript.org/

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?