←back to thread

Unexpected productivity boost of Rust

(lubeno.dev)
517 points bkolobara | 1 comments | 27 Aug 25 15:48 UTC | HN request time: 0s | source
Show context
BinaryIgor ◴[27 Aug 25 17:30 UTC] No.45042483[source]▶
Don't most of the benefits just come down to using a statically typed and thus compiled language? Be it Java, Go or C++; TypeScript is trickier, because it compiles to JavaScript and inherits some issues, but it's still fine.

I know that Rust provides some additional compile-time checks because of its stricter type system, but it doesn't come for free - it's harder to learn and arguably to read

replies(17): >>45042692 #>>45043045 #>>45043105 #>>45043148 #>>45043241 #>>45043589 #>>45044559 #>>45045202 #>>45045331 #>>45046496 #>>45047159 #>>45047203 #>>45047415 #>>45048640 #>>45048825 #>>45049254 #>>45050991 #
pornel ◴[27 Aug 25 18:19 UTC] No.45043105[source]▶
To a large extent yes, but Rust adds more dimensions to the type system: ownership, shared vs exclusive access, thread safety, mutually-exclusive fields (sum types).

Ownership/borrowing clarifies whether function arguments are given only temporarily to view during the call, or whether they're given to the function to keep and use exclusively. This ensures there won't be any surprise action at distance when the data is mutated, because it's always clear who can do that. In large programs, and when using 3rd party libraries, this is incredibly useful. Compare that to that golang, which has types for slices, but the type system has no opinion on whether data can be appended to a slice or not (what happens depends on capacity at runtime), and you can't lend a slice as a temporary read-only view (without hiding it behind an abstraction that isn't a slice type any more).

Thread safety in the type system reliably catches at compile time a class of data race errors that in other languages could be nearly impossible to find and debug, or at very least would require catching at run time under a sanitizer.

replies(4): >>45043414 #>>45043440 #>>45047837 #>>45052706 #
zelphirkalt ◴[27 Aug 25 18:44 UTC] No.45043414[source]▶
What annoys me about borrowing is, that my default mode of operating is to not mutate things if I can avoid it, and I go to some length in avoiding it, but Rust then forces me to copy or clone, to be able to use things, that I won't mutate anyway, after passing them to another procedure. That creates a lot of mental and syntactical overhead. While in an FP language you are passing values and the assumption is already, that you will not mutate things you pass as arguments and as such there is no need to have extra stuff to do, in order to pass things and later still use them.

Basically, I don't need ownership, if I don't mutate things. It would be nice to have ownership as a concept, in case I do decide to mutate things, but it sucks to have to pay attention to it, when I don't mutate and to carry that around all the time in the code.

replies(5): >>45043496 #>>45043550 #>>45043678 #>>45044243 #>>45050174 #
vlovich123 ◴[27 Aug 25 19:48 UTC] No.45044243[source]▶
It sounds like you may not actually know Rust then because non-owning borrow and ownership are directly expressible within the type system:

Non-owning non mutating borrow that doesn’t require you to clone/copy:

    fn foo(v: &SomeValue)
Transfer of ownership, no clone/copy needed, non mutating:

    fn foo(v: SomeValue)
Transfer of ownership, foo can mutate:

    fn foo(mut v: SomeValue)
AFAIK rust already supports all the different expressivity you’re asking for. But if you need two things to maintain ownership over a value, then you have to clone by definition, wrapping in Rc/Arc as needed if you want a single version of the underlying value. You may need to do more syntax juggling than with F# (I don’t know the language so I can’t speak to it) but that’s a tradeoff of being a system engineering language and targeting a completely different spot on the perf target.
replies(2): >>45044516 #>>45049874 #
zelphirkalt ◴[27 Aug 25 20:09 UTC] No.45044516[source]▶
Can you give examples of the calls for these procedures? Because in my experience when I pass a value (not a reference), then I must borrow the value and cannot use it later in the calling procedure. Passing a reference of course is something different. That comes with its own additional syntax that is needed for when you want to do something with the thing that is referred to.
replies(2): >>45044985 #>>45045709 #
1. vlovich123 ◴[27 Aug 25 21:46 UTC] No.45045709[source]▶
If all you're doing is immutable access, you are perfectly free to immutably borrow the value as many times as you want (even in a multithreaded environment provided T is Send):

    let v = SomeValue { ... }
    foo(&v);
    foo(&v);
    eprintln!("{}", v.xyz);
You have to take a reference. I'm not sure how you'd like to represent "I pass a non-reference value to a function but still retain ownership without copying" - like what if foo stored the value somewhere? Without a clone/copy to give an isolated instance, you've potentially now got two owners - foo and the caller of foo which isn't legal as ownership is strictly unique. If F# lets you do this, it's likely only because it's generating an implicit copy for you (which Rust is will do transparently for you when you declare your type inheriting Copy).

But otherwise I'm not clear what ownership semantics you're trying to express - would be helpful if you could give an example.