vascocosta

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.

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.

Thanks!

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...

Any idea when Pixel86 is going to be available again or how/where to get an ITX-Llama system?

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.

TIL about distrobox. It seems like a really neat way to use containers with good host distro integration.

I didn't know this one, thanks. Looks interesting as well.

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.