4 ms·

> Rust: I'm not afraid to admit it - Rust is just too complicated for use as an aging and cranky solo developer. I'm nearly 51 and currently learning Rust. Th

> Rust: I'm not afraid to admit it - Rust is just too complicated for use as an aging and cranky solo developer. I'm nearly 51 and currently learning Rust. The first 10 hours of it were horribly slow, but it isn't as steep of a learning curve as Optimal Control Theory.

nu11ptr 4y ago
Learning curve is straight up for many with the borrow checker, but once you are over that hump, and it comes pretty quick for most, Rust is no harder than any other language.
- moldavi 4y ago
  Easier than C or C++ for sure. But I definitely wouldn't say that Rust as easy as a GC'd language like Java or Go. They have strictly less constraints to deal with, they can let you use the simplest pattern for the situation, and (in my experience) they have less superfluous refactoring sessions due to the overly conservative nature of the borrow checker. I like how Matt Welsh put it in https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautionary-tale-42ab823d9454 https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautio...: > What really bites is when you need to change the type signature of a load-bearing interface and find yourself spending hours changing every place where the type is used only to see if your initial stab at something is feasible. And then redoing all of that work when you realize you need to change it again. Perhaps you're instead speaking of a specific situation or kind of program where the borrow checker happens to be no harder than any other language?
- tgv 4y ago
  In my experience, it depends heavily on the kind of thing you're writing. I could write some small programs in it, no problem: a rather complex, text-based calculator was easy and elegant to write with function arguments, a game server monitor, some tools for a cryptography course, an FFT analyzer that reads from WAV or AIFF, etc. Then I tried to port my rather efficient Earley parser (https://en.wikipedia.org/wiki/Earley_parser https://en.wikipedia.org/wiki/Earley_parser) from C. Constructing the item set efficiently wasn't that hard, but constructing the forest (set of syntactic trees) was. In C, it was basically free by using some pointer sharing, but I couldn't get that done in Rust. Perhaps there's some clever trick I couldn't think of, but I couldn't get it anywhere near C's speed. And since the ultimate goal of that parser includes further memory shenanigans (unification of results yielded by the rules), I dropped the project. At my job, I'm writing in Go. I fairly sure I could easily port the C code to that. It would probably run a bit slower, but the algorithm and data structures would be readable, and extendable. So: it depends.
julianeon 4y ago
I'm close in age to you but that was one part of the article that resonate w me. I'm often writing little scripts for my computer or things that a dozen people will use, if I'm lucky. If the program 'crashes' it barely matters. It feels like, in Rust, I have to carefully choose my data type and use the applicable methods (not always intuitive), whereas in Nim or Go, I can basically just slap something together and then have an error condition which is like 'if you die, just print that you died and quit.' And that pretty much meets my needs. The extra safety isn't actually protecting anything valuable, in my case.
- lamontcg 4y ago
  I mean "unwrap()" and "panic!() are right there for "blow up and don't care", if you're really just doing throwaway scripting that should be enough. And the "?" operator is way more ergonomic for throwing actual errors up a level than all the boilerplate in Go. The pattern matching with `match` `if let` and `let else` are pretty easy to use to unwrap Result and Option enums. And then the "anyhow" or "thiserror" crates make it all more ergonomic. The end result is something is much more readable than all the error handling in Go, while still being at least as safe if not more safe. Plus you wind up playing with Monads without needing to know what the hell an endofunctor is. And there's no null/nil, while Options have to be explicit and if you squint (because of the presbyopia) they look kinda like the nillable stuff in C# 8.0
  - rbetts 4y ago
    Kind of an ironic reply - naming 10 Rust features and libraries vs. an `if` check in Go to argue that Rust has simpler ergonomics for throw-away code.
    - lamontcg 4y ago
      My response covered the gamut from throw away code up to error handling in professionally written code, with a diversion through "null" handling. To reiterate, for throw away code (or tests) unwrap() and panic!() will work just fine.

nu11ptr 4y ago

Learning curve is straight up for many with the borrow checker, but once you are over that hump, and it comes pretty quick for most, Rust is no harder than any other language.

moldavi 4y ago
Easier than C or C++ for sure. But I definitely wouldn't say that Rust as easy as a GC'd language like Java or Go. They have strictly less constraints to deal with, they can let you use the simplest pattern for the situation, and (in my experience) they have less superfluous refactoring sessions due to the overly conservative nature of the borrow checker. I like how Matt Welsh put it in https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautionary-tale-42ab823d9454 https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautio...: > What really bites is when you need to change the type signature of a load-bearing interface and find yourself spending hours changing every place where the type is used only to see if your initial stab at something is feasible. And then redoing all of that work when you realize you need to change it again. Perhaps you're instead speaking of a specific situation or kind of program where the borrow checker happens to be no harder than any other language?
tgv 4y ago
In my experience, it depends heavily on the kind of thing you're writing. I could write some small programs in it, no problem: a rather complex, text-based calculator was easy and elegant to write with function arguments, a game server monitor, some tools for a cryptography course, an FFT analyzer that reads from WAV or AIFF, etc. Then I tried to port my rather efficient Earley parser (https://en.wikipedia.org/wiki/Earley_parser https://en.wikipedia.org/wiki/Earley_parser) from C. Constructing the item set efficiently wasn't that hard, but constructing the forest (set of syntactic trees) was. In C, it was basically free by using some pointer sharing, but I couldn't get that done in Rust. Perhaps there's some clever trick I couldn't think of, but I couldn't get it anywhere near C's speed. And since the ultimate goal of that parser includes further memory shenanigans (unification of results yielded by the rules), I dropped the project. At my job, I'm writing in Go. I fairly sure I could easily port the C code to that. It would probably run a bit slower, but the algorithm and data structures would be readable, and extendable. So: it depends.

julianeon 4y ago

I'm close in age to you but that was one part of the article that resonate w me. I'm often writing little scripts for my computer or things that a dozen people will use, if I'm lucky. If the program 'crashes' it barely matters. It feels like, in Rust, I have to carefully choose my data type and use the applicable methods (not always intuitive), whereas in Nim or Go, I can basically just slap something together and then have an error condition which is like 'if you die, just print that you died and quit.' And that pretty much meets my needs. The extra safety isn't actually protecting anything valuable, in my case.

lamontcg 4y ago
I mean "unwrap()" and "panic!() are right there for "blow up and don't care", if you're really just doing throwaway scripting that should be enough. And the "?" operator is way more ergonomic for throwing actual errors up a level than all the boilerplate in Go. The pattern matching with `match` `if let` and `let else` are pretty easy to use to unwrap Result and Option enums. And then the "anyhow" or "thiserror" crates make it all more ergonomic. The end result is something is much more readable than all the error handling in Go, while still being at least as safe if not more safe. Plus you wind up playing with Monads without needing to know what the hell an endofunctor is. And there's no null/nil, while Options have to be explicit and if you squint (because of the presbyopia) they look kinda like the nillable stuff in C# 8.0
- rbetts 4y ago
  Kind of an ironic reply - naming 10 Rust features and libraries vs. an `if` check in Go to argue that Rust has simpler ergonomics for throw-away code.
  - lamontcg 4y ago
    My response covered the gamut from throw away code up to error handling in professionally written code, with a diversion through "null" handling. To reiterate, for throw away code (or tests) unwrap() and panic!() will work just fine.