Remix.run Logo
gorjusborg 5 hours ago

Years ago, when I initially picked up Rust, I loved it. It does a lot of things right. At the same time, though, I knew there was a possibility of it going wrong in two opposite directions:

1. Developers balked at being required to take on the cognitive load required to allow GC-less memory management

2. Developers wore their ability to take on that cognitive load as a badge of honor, despite it not being in their best interest

I eventually came to the decision to stop developing in Rust, despite its popularity. It is really cool that its creators pulled it off. It was quite an achievement, given how different it was when it came out. I think that if I had to implement a critical library I would consider using Rust for it, but as a general programming language I want something that allows me to focus my mental facilities on the complexities of the actual problem domain, and I felt that it was too often too difficult to do that with Rust.

K0nserv 4 hours ago | parent | next [-]

It's not quite a fully formed argument, but I'm coming to the view that Rust mostly requires less cognitive load than other languages. I'm coming at this from the perspective of "cognitive load" meaning, roughly "the measure of the number of things you need to keep in working memory". Rust is no doubt difficult to learn, there are many concepts and a lot of syntax, but when you grasp it cognitive load is actually lower. Rust encodes so much more about the program in text than peer languages so there are fewer things to keep in your head. One good example of this is pointer lifetimes in Zig and C which you have to keep in your head, whereas in Rust you don't.

My own appreciation for Rust is rooted in humility. I know I'm an overgrown monkey prone to all kinds of mistakes. I appreciate Rust for helping me avoid that side of me

com2kid 3 hours ago | parent | next [-]

The mentality around lifetimes is different in Zig if you are using it for the correct types of problems.

For example, a command line utility. In a CLI tool you typically don't free memory. You just allocate and exit and let the OS clean up memory.

Historically compilers were all like this, they didn't free memory, they just compiled a single file and then exited! This ended up being a problem when compilers moved more into a service model (constant compilation in the background, needing to do whole program optimization, loading into memory and being called on demand to compile snippets, etc), but for certain problem classes, not worrying about memory safety is just fine.

Zig makes it easy to create an allocator, use it, then just free up all the memory in that region.

Right tool for the job and all that.

whytevuhuni 2 hours ago | parent | next [-]

I've been having an absolutely great time with Rust's bumpalo crate, which works very similarly. The lifetime protection still works great, and it's actually a lot more permissive than normal Rust, since it's the same lifetime everywhere.

The sad exception is obviously that Rust's std collections are not built on top of it, and neither is almost anything else.

But nevertheless, I think this means it's not a Zig vs Rust thing, it's a Zig stdlib vs Rust stdlib thing, and Rust's stdlib can be replaced via #[no_std]. In the far future, it's likely someone will make a Zig-like stdlib for Rust too, with a &dyn Allocator inside collections.

zozbot234 2 hours ago | parent [-]

> In the far future, it's likely someone will make a Zig-like stdlib for Rust too, with a &dyn Allocator inside collections.

This exists in the nightly edition of Rust, but is unlikely to become a feature in its current form because the alternative of "Storages" seems to be a lot more flexible and to have broader applicability.

dnautics 3 hours ago | parent | prev [-]

I'm not convinced that you can't borrow check in zig... (disclaimer, i'm working on compile time memory safety for zig)

DetroitThrow 39 minutes ago | parent [-]

I had no idea you were working on Zig dnautics.

If you were to add borrow checking to Zig, it would make it much easier to justify using it at my current workplace.

zozbot234 4 hours ago | parent | prev | next [-]

> Rust is no doubt difficult to learn, there are many concepts and a lot of syntax

People love to say this, but C++ is routinely taught as a first programming language to novice programmers (this used to be even more clearly the case before Java and Python largely took on that role) and Rust is undoubtedly simpler than C++.

tialaramex 20 minutes ago | parent | next [-]

C++ as First Language seems like an especially terrible idea to me. Maybe I should take a few months and go do one of those courses and see whether it's as bad as I expect.

The nice thing about Rust as First Language (which I'm not sure I'd endorse, but it can't be as bad as C++) is that because safe Rust ropes off so many footguns it's extremely unlikely that you'll be seriously injured by your lack of understanding as a beginner. You may not be able to do something because you didn't yet understand how - or you might do something in a terribly sub-optimal way, but you're not likely to accidentally write nonsense without realising and have that seem to work.

For example yesterday there was that piece where the author seems to have misunderstood how heap allocation works in Rust. But, in safe Rust that's actually harmless. If they write their mistake it won't compile, maybe they figure out why, maybe they give up and can't use heap allocation until they learn more.

I haven't thought too hard about Zig as first language, because to me the instability rules that out. Lecturers hate teaching moving targets.

vablings 2 hours ago | parent | prev | next [-]

I gave up on a C++ after trying to learn on and off for years. LNK1009 still haunts me in my sleep. I am now an avid self-taught rust programmer and I feel like I have the power to create almost anything I can imagine using rust. This is great for hobby people

tehjoker 3 hours ago | parent | prev [-]

That's true, but as someone that doesn't do much rust, C++ is a language where there are fewer restrictions and you can use little parts of the language, whereas Rust is supposed to be a simpler language overall, but with more concepts to learn up-front to prevent things that happen where there are no rules....

zozbot234 3 hours ago | parent | next [-]

You can use "little parts of the language" in Rust too; the cleanest and most foundational part of Rust is pure value-based programming with no mutability or referencing at all, much like in a functional language (but with affine types!). Everything else is built quite cleanly on top of that foundation, even interior mutability which is often considered incredibly obscure. (It's called "interior" because the outer cell's identity doesn't really mutate, even though its content obviously does.)

bsder 3 hours ago | parent | prev [-]

Precisely.

You can subset C++ and still knock out a program.

You cannot subset Rust and still create a program.

tialaramex 7 minutes ago | parent | next [-]

This seems like a very strange position, code written for Rust in 2015 still works, and in 2015 Rust just doesn't have const generics†, or async, or I/O safety, so... how is that not a subset of the language at it stands today ?

† As you're apparently a C++ programmer you would call these "Non-type template parameters"

simonask an hour ago | parent | prev [-]

You can absolutely make a complete, featureful program in Rust without naming a single lifetime, or even without dealing with a single reference/borrow.

But Rust is a dramatically smaller language than C++. The various subsets of C++ people usually carve out tend to be focused on particular styles of programming, like “no exceptions” or “no RTTI”. Notably never things like “signed integer overflow is now defined”, or “std::launder() is now unnecessary”.

DetroitThrow an hour ago | parent | prev [-]

>My own appreciation for Rust is rooted in humility. I know I'm an overgrown monkey prone to all kinds of mistakes. I appreciate Rust for helping me avoid that side of me

I think we've heard these arguments ad nauseum at this point, but the longer I use Rust for ensuring long-term maintenance burden is low in large systems that I have to be absolutely, 10,000% correct with the way I manage memory the more it seems to reduce the effort required to make changes to these large systems.

In scenarios where multiple people aren't maintaining a highly robust system over a long period of time, e.g. a small video game, I think I'd absolutely prefer Zig or C++ where I might get faster iteration speed and an easier ability to hit an escape hatch without putting unsafe everywhere.

zozbot234 4 hours ago | parent | prev | next [-]

Rust does not require GC-less memory management. It supports reference counting out of the box, and reference counting is a kind of GC. It's not inherently any harder to use than Swift (another memory-safe language) which plenty of average developers use to code for Apple platforms.

simonask an hour ago | parent | next [-]

I don’t think it’s a useful observation. Lots of people come to Rust from OOP languages and try to make everything `Arc<dyn Interface>`, and it immediately fails, to their great frustration.

Do not do this.

pron an hour ago | parent | prev [-]

I think it is significantly harder to use than Swift, and inherently so.

pron an hour ago | parent | prev | next [-]

> I eventually came to the decision to stop developing in Rust, despite its popularity

It's also not popular for a language that old. It's roughly as popular as Ada was when it was the same age Rust is today (there may not have been as many projects written in Ada then, but there were certainly much bigger/more important projects being written in Ada then). It's not nearly as popular as C, or C++, or Java, or C#, or Go were at that age.

The relatively small number of developers who program in Rust, and the smaller still number of them who use it at work, are certainly very enthusuastic about it, but an enthusiastic "base" and popularity are very different things.

mountainriver an hour ago | parent | prev | next [-]

I feel like vibe coding has completely changed this paradigm. Now all I care about is how fast and reliable the language is.

azaras 5 hours ago | parent | prev [-]

What are you developing in?

gorjusborg 4 hours ago | parent [-]

Depends on the problem at hand.

Zig where I used to use C/Rust (but admittedly I spent the least time here).

Go where I used to use Java.

Bun/Node for typescript/javascript, where each is appropriate, but I favor Bun for standalone application programming and local scripting.

littlestymaar 4 hours ago | parent [-]

> Zig where I used to use C/Rust (but admittedly I spent the least time here).

I really don't understand how that fit with the “I want something that allows me to focus my mental facilities on the complexities of the actual problem domain”.

For low-level stuff, Rust allows to offload the cognitive load of maintaining the ownership requirements to the machine. On the opposite, Zig is exactly like C as it forces you to think about it all the time or you just shoot yourself in the foot at the first opportunity…

For stuff that can be done with managed languages, then absolutely, the GC allows to completely ignore that aspect, at the cost of some performance you don't always care about because how fast the modern hardware is.