top | item 45444261

(no title)

IceHegel | 5 months ago

I don’t think Rust syntax and patterns (no classes) are especially elegant for many tasks. I can’t express the behavior of a system as cleanly in Rust as TypeScript, C#, go or Python. I know that’s not what it was designed for, but a guy can dream.

But what Rust has is the best tooling bar none(cargo, build system, compile time checks, ease of first use). The tooling is actually more important than the borrow checker and memory safety in my opinion.

If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language. It avoided the fragmentation of JS/TS (npm, yarn, pnpm, bun, deno) and dep hell of Python (which was a nightmare until uv).

If Rust didn’t have the syntax warts (macros), it would be eating the world.

discuss

order

foota|5 months ago

This is a bizarre take to me, what do you want to do with classes that aren't supported by structs and traits? Imo the usability issues with rust arise from the borrow checker and associated complexity + restrictions on patterns, so I'm surprised that you're citing macros and classes.

AnimalMuppet|5 months ago

Access control.

Here's a struct that maintains an invariant - say, that field a is less than field b. That invariant should be set when it is created.

You find a bug where a is greater than b. Where is the bug? With a struct, it can be anywhere in the code - any line that touches the struct. But with a (well designed) class, a and b are private, and so you only have to look at lines of code within the class. The surface area where the bug can be is much smaller.

The bigger the code base and the more well-used the class is, the more this matters.

the__alchemist|5 months ago

I'm confused too! When I write Python, I do it in a similar style as rust, but knowing the classes and enums are sloppier than rust's; regarding mutation for example.

mrheosuper|5 months ago

>dep hell

As a C programmer, i'm always a little panic how a small Rust Program can pull in that many crates when compiling.

james7132|5 months ago

Once you understand that a crate is the translation unit in Rust, it doesn't feel as bad. Most medium to large Rust project's will separate out their code into separate crates for both organization and compile time.

I've definitely cloned down my fair share of C projects, mashed the make command into my terminal, and watched the gcc/clang logs fly by and never batted an eye beyond checking the sha256sum on any downloaded tarballs.

There's a valid argument to be made about supply chain attacks, but there does exist tooling to lock that down, and I would argue that any serious software development firm should be auditing every third party dependency they take on.

sitzkrieg|5 months ago

> If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language

zig is very comparable, and much faster at doing so. zig also comes with a build system, libc and can compile c programs. its a better c compiler and build system than most, lol.

treyd|5 months ago

But Zig doesn't have the very sophisticated type system that Rust has. Nor does it, importantly to DARPA, have the memory safety that Rust does.

heavyset_go|5 months ago

These are honest questions and not rhetorical: how does Zig handle versions with syntax changes or breaking changes?

Can you mix Zig libraries written X years ago with modern Zig? Will today's code work in 5-10 years if I want to use it in a project then?

AbuAssar|5 months ago

> It avoided the fragmentation of JS/TS (npm, yarn, pnpm, bun, deno)

just use npm, the others are just more options, thersr is no "fragmentation"

iberator|5 months ago

Not everyone likes OOP you know? Some people love low abstraction code.

hu3|5 months ago

> If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language.

I beg to differ because Go has a large standard library which means less dependencies than Rust on average.

AlotOfReading|5 months ago

It's not usually the standard library or dependencies that create the issues I've seen. The teams I work with producing Go tools (across multiple companies) invariably require carefully orchestrated dev environments that are nigh-unreproducible. It's 50/50 on whether I can actually build a random project first try without reading the instructions if CGO is involved, which seems to be all of them.

My experience with random rust projects is that they usually "just build", with limited exceptions like weird embedded stuff.