Hacker News Reader

> Rust is not hard. Rust has a standard library that looks an awful lot like Python or Ruby, with similarly named methods.

I would read this in regard to Go and not so much in regards to Zig. Go is insanely productive, and while you're not going to match something like Django in terms of delivery speed with anything in Go, you almost can... and you can do it without using a single external dependency. Go loses a little of this in the embeded space, where it's not quite as simple, but the opinonated approach is still very productive even here.

I can't think of any language where I can produce something as quickly as I can in Go with the use of nothing but the standard library. Even when you do reach for a framework like SQLC, you can run the external parts in total isolation if that's your thing.

I will say that working with the interoperability of Zig in our C for Python binaries has been very easy, which it wasn't for Rust. This doesn't mean it's actually easier for other people, but it sure was for me.

> This is one of Rust's superpowers !

In some industries it's really not.

Rust is hard in that it gives you a ton of rope to hang yourself with, and some people are just hell bent on hanging themselves.

I find Rust quite easy most of the time. I enjoy the hell out of it and generally write Rust not too different than i'd have written my Go programs (i use less channels in Rust though). But i do think my comment about rope is true. Some people just can't seem to help themselves.

That seems like an odd characterization of Rust. The borrow checker and all the other type safety features, as well as features like send/sync are all about not giving you rope to hang yourself with.

The rope in my example is complexity. Ie choosing to use "all teh features" when you don't need or perhaps even want to. Eg sometimes a simple clone is fine. Sometimes you don't need to opt for every generic and performance minded feature Rust offers - which are numerous.

Though, i think my statement is missing something. I moved from Go to Rust because i found that Rust gave me better tooling to encapsulate and reuse logic. Eg Iterators are more complex under the hood, but my observed complexity was lower in Rust compared to Go by way of better, more generalized code reuse. So in this example i actually found Go to be more complex.

So maybe a more elaborated phrase would be something like Rust gives you more visible rope to hang yourself with.. but that doesn't sound as nice. I still like my original phrase heh.

I would love to see a language that is to C what Rust is to C++. Something a more average human brain like mine can understand. Keep the no-gc memory safety things, but simplify everything else a thousand times.

Not saying that should replace Rust. Both could exist side by side like C and C++.

I'm curious about what you'd want simplified. Remove traits? What other things are there to even simplify if you're going to keep the borrow checker?

I'm the last person to be able to answer that. There would be Chesterton's fences everywhere for one thing.

Better question is what to add to something like C. The bare minimum to make it perfectly safe. Then stop there.

I feel like it is the opposite, Go gives you a ton of rope to hang yourself with and hopefully you will notice that you did: error handing is essentially optional, there are no sum types and no exhaustiveness checks, the stdlib does things like assume filepaths are valid strings, if you forget to assign something it just becomes zero regardless of whether it’s semantically reasonable for your program to do that, no nullability checking enforcement for pointers, etc.

Rust OTOH is obsessively precise about enforcing these sort of things.

Of course Rust has a lot of features and compiles slower.

> error handing is essentially optional

Theoretically optional, maybe.

> the stdlib does things like assume filepaths are valid strings

A Go string is just an array of bytes.

The rest is true enough, but Rust doesn't offer just the bare minimum features to cover those weaknesses, it offers 10x the complexity. Is that worth it?

What do people generally write in Rust? I've tried it a couple of times but I keep running up against the "immutable variable" problem, and I don't really understand why they're a thing.

> but I keep running up against the "immutable variable" problem

...Is that not what mut is for? I'm a bit confused what you're talking about here.

I don't really get immutable variables, or why you'd want to make copies of things so now you've got an updated variable and an out-of-date variable. Isn't that just asking for bugs?

As with many things, it comes down to tradeoffs. Immutable variables have one set of characteristics/benefits/drawbacks, and mutable variables have another. Different people will prefer one over the other, different scenarios will favor one over the other, and that's expected.

That being said, off the top of my head I think immutability is typically seen to have two primary benefits:

- No "spooky action at a distance" is probably the biggest draw. Immutability means no surprises due to something else you didn't expect mutating something out from under you. This is particularly relevant in larger codebases/teams and when sharing stuff in concurrent/parallel code.

- Potential performance benefits. Immutable objects can be shared freely. Safe subviews are cheap to make. You can skip making defensive copies. There are some interesting data structures which rely on their elements being immutable (e.g., persistent data structures). Lazy evaluation is more feasible. So on and so forth.

Rust is far from the first language to encourage immutability to the extent it does - making immutable objects has been a recommendation in Java for over two decades at this point, for example, to say nothing of its use of immutable strings from the start, and functional programming languages have been working with it even longer. Rust also has one nice thing as well which helps address this concern:

> or why you'd want to make copies of things so now you've got an updated variable and an out-of-date variable

The best way to avoid this in Rust (and other languages with similarly capable type systems) is to take advantage of how Rust's move semantics work to make the old value inaccessible after it's consumed. This completely eliminates the possibility that the old values anre accidentally used. Lints that catch unused values provide additional guardrails.

Obviously this isn't a universally applicable technique, but it's a nice tool in the toolbox.

In the end, though, it's a tradeoff, as I said. It's still possible to accidentally use old values, but the Rust devs (and the community in general, I think) seem to have concluded that the benefits outweigh the drawbacks, especially since immutability is just a default rather than a hard rule.

Same. Zig's niche is in the vein of languages that encourages using pointers for business logic. If you like this style, Rust and most other new languages aren't an option.

This confuses me. In zig null pointers are illegal, and I have yet to run into any case that should be addressed by using pointer arithmetic, that's all taken care of with slices.

Seems like it's just a comment written by someone with little to no experience using zig.

One question about your functional point: where can I learn functional programming in terms of organization of large codebases?

Perhaps it is because DDD books and the like usually have strong object oriented biases, but whenever I read about functional programming patterns I’m never clear on how to go from exercise stuff to something that can work in a real world monolith for example.

And to be clear I’m not saying functional programming is worse at that, simply that I have not been able to find information on the subject as easily.

There are a lot of lectures/speeches by the creator of elm and Richard Feldman that talk about how to think "functionally"

Here is one about how to structure a project (roughly)

https://youtube.com/watch?v=XpDsk374LDE

I also think looking at the source code for elm and its website, as well as the elm real world example help a lot.

This seems good: https://www.youtube.com/watch?v=WRoYKBXWJes

> I feel like Zig is for the C / C++ developers that really dislike Rust.

Also my feeling. Writing this as a former C++ developer who really likes Rust :)

C++ developers are monstruosities

How so?

> This desire of wanting to write OO-style code makes me think that people who want OO-style code are the ones having a lot of struggle or frustration with Rust's ergonomics.

I believe this is actually a significant source of consternation. I teach Rust to students, and I find those without a C/C++ background take to it more naturally than those who have a lot of experience with those languages. People with a C/C++ background approach Rust like C/C++ and fight it the whole way, whereas people without that background approach Rust as Rust, and they have a better time with it.

> Rust is not hard. Rust has a standard library that looks an awful lot like Python or Ruby, with similarly named methods.

> If you're trying to shoehorn some novel type of yours into a particular trait interface so you can pass trait objects around, sure. Maybe you are going to have to memorize a lot more. But I'd ask why you write code like that unless you're writing a library.

I think that you are missing the point - they're not saying (at least in my head) "Rust is hard because of all the abstractions" but, more "Rust is hard because you are having to explain to the COMPILER [more explicitly] what you mean (via all these abstractions)

And I think that that's a valid assessment (hell, most Rustaceans will point to this as a feature, not a bug)

> Rust has a standard library that looks an awful lot like Python or Ruby, with similarly named methods.

Can you elaborate? While they obviously have overlap, Rust's stdlib is deliberately minimal (you don't even get RNG without hitting crates.io), whereas Python's is gigantic. And in actual use, they tend to feel extremely different.

Rust is hard because it's just difficult to read.

If you know Java, you can read C#, JavaScript, Dart, and Haxe and know what's going on. You can probably figure out Go.

Rust is like learning how to program again.

Back when I was young and tried C++, I was like this is hard and I can't do this.

Then I found JavaScript and everything was great.

What I really want is JS that complies into small binaries and runs faster than C. Maybe clean up the npm dependency tree. Have a professional commite vet every package.

I don't think that's possible, but I can dream