I'm exactly in the same boat. 25+ years of experience and I use agentic coding exactly to learn better patterns. I often let it implement something, read the code, learn the pattern, confirm it's a good practice and then code myself manually another section of the code.
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.
GluonScript really doesn't need a garbage collector, because at the end of the day when a script is executing, it is just safe Rust code evaluating expressions. So it's just a Rust program running really, with its automatic static memory management guarantees.
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.
Really interesting read, especially after I released the initial version of my own interpreter which is also an AST-walking interpreter. My main goal was to understand at a basic level what it takes to build an interpreted programming language.
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:
I know, but I often use Golang for two reasons: 1. avoids confusion, no matter how unlikely it is in a context like HN, and 2. search engine "findability".
I totally resonate with the author of the post. My main requirement to enjoy a language deeply is often simplicity, so I love languages like, C, Golang, Odin and Zig.
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.
That's exactly what's compelling to me as well. As an absolute fan of KDE and all its features, as well as stability. Who better to seamlessly integrate everything around a KDE desktop than themselves? KDE neon had potential as well, but I really like the notion of an immutable base system and less surprises during an upgrade.
A long time ago I have used all BSDs and loved them. Eventually the performance of Linux hooked me back, but I guess it's always a good time to go BSD again. I miss the predictability of the upgrades.
Or you can try to install whatever custom packages you need under $HOME, without the need for any special permissions or FS overlays? But yes, saving snapshots is also a good solution.
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.
Personally I'm interested in distros with an immutable base system. After decades of a lot of tinkering with all sorts of distros, I value a stable core more than anything else. If I want to tinker and/or install/compile packages I can do so in my $HOME folder.
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.
I agree with you in principle. However, this distro in particular makes use of an immutable base system, which although not new, is definitely not extremely common among Linux distros.
No. Obviously Rust is popular outside HN and for instance in my case and other people that I know the interest for Rust is totally unrelated to HN or any other specific platform for that matter.
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.
I pronounce as CLI as well, at least mentally whenever I read it. I don't often, if ever get the chance to say it out loud, so I wouldn't know. English is not my native language so I guess "cee el eye" would not be how I'd say it.
> One possible interpretation is that the brakes when manually applied are insufficient to stop the vehicle when the counterweight provided by the cable is absent.
> 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.
One of the issues is that the body consists of a wooden frame, surrounded by a thin sheet of steel to avoid extra weight. So it's not very strong, plus the bulk of the 14 ton mass lies on the bottom where the bogies are. When it derailed and tipped over, the strong structure underneath the cabin sort of crushed the lightweight structure where the passengers were.
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.
It's my understanding that this particular funicular system uses eight shoe brakes, where rubber pads basically clamp a metal track (from above and below) causing friction.
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?
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.