For example, local variables of a function get destroyed on function exit no matter what and you can't prevent it by adding lifetime annotation to a local variable reference you are trying to return.
That was a stumbling block for me.
Would you mind if I made a pull request to the Rust book adding your explaination to the lifetime chapter ?
> Lifetime annotations don’t change how long any of the references involved live. In the same way that functions can accept any type when the signature specifies a generic type parameter, functions can accept references with any lifetime when the signature specifies a generic lifetime parameter. What lifetime annotations do is relate the lifetimes of multiple references to each other.
Thanks :)
"Descriptive and not prescriptive" part probably comes from stackoverflow. I don't remember exactly.
Lastly, I would first advise you to work through https://learnxinyminutes.com/docs/rust/ to get a feel of the language (like dipping your toes into the water). If you like what you see, then continue from the Rust book: https://doc.rust-lang.org/book/second-edition/ .
And most importantly remember to have fun!
Mozilla's IRC server has a #rust-beginners channel that is like, overwhelmingly helpful. Go and ask stupid questions.
"The Rust Programming Language" is good:
https://doc.rust-lang.org/book/second-edition/
Knowing the difference between the stack and the heap, and having a picture of it in your head and understanding which variables go where, and what happens to the stack when calling and returning from functions, is pretty important. (Python wouldn't give you this intuition, although programming in something like Java might.)
I half-assed learned to code in C++ for scientific purposes. Later I got deeper into Rust, and it's made me a better, safer C++ programmer when I run into C++ code.
Really looking forward to learning from your material, when it's ready.
Anyway, the other comments about reading the docs and building things are correct. I'd just point out two things in addition.
1) Don't feel like you have to go write some impressive low level application just because the language is lower level - fizzbuzz works fine too.
2) Don't worry too much about whether you're strong enough on systems concepts. It's not a class you fail if you show up unprepared for; it's (presumably) play time you're engaging in to scratch your own itch. You'll make mistakes but that's not something to be avoided, it's the only way to learn.
You might give Nim[1] a try.
Coming from Python, you might find Nim's syntax (and significant whitespace) familiar. It took me (also a Python programmer) a week or so before I was able to write small programs in Nim.
(Don't let "not yet v1.0" to turn you off)
One thing that put me off in the end was that it didn't support native OS threads (I have the same problem with Racket). Has threading support improved over the years?
The main push in this area is Multicore OCaml[1]. I don't track OCaml closely enough to know how getting this into the main compiler is going.
http://caml.inria.fr/pub/docs/manual-ocaml/libref/Thread.htm...
However, because I am used to writing multithreaded code using pthread or std::thread, I find the standard OCaml model uncomfortable and limiting. Its mostly a matter of personal taste but this is the reason I stopped using OCaml.
Nope, different structs could have fields named the same.
For instance there is an instance of the Racket VM per place and this makes them heavier than it would be in a standard system programming language language such as C, C++ or Rust.
I am not saying it is better or worse -- just different.
[1] https://www.cs.utah.edu/plt/publications/dls11-tsffd.pdf
Regarding books, Real World Ocaml is very well written, although some examples might need tweaking.
Mostly wondering how people ship stuff if there are different variants of std libs? Say you write your code entirely using one std lib and then try to share it (the code that is) with somebody who uses a different std lib, then the onus of learning the new std lib is entirely on him, right? How does that work for teams then? I know that Jane Street is a big user and so they have considerable influence. That being said, does the std lib (the one bundled with the distro) have enough features (like all the necessary data structures, for instance) to make using it viable in a non-trivial project (off the top of my head, say writing a very simple web server)? If so then, I suppose that's good enough.
Any recommendations for learning material? I have a copy of "Practical OCaml", don't really like it. INRIA's materials seem quite substantial, but more like reference.
The migration from standard stdlib to alternate ones is fairly trivial(some signatures might differ but typed language means the compiler will catch them for you), so you can start using the stdlib and if you feel like writing some trivial things that should be in the stdlib or you need some advanced data structures you can use the alternate ones.
Also you need `lwt`(most people prefer this)/`async` library for writing concurrent programs like a webserver. `Cohttp` is a good library for doing http based client/servers. I strongly recommend `Real world ocaml` and the reference manual is excellent at looking up some new type-level features. Also reading well-known libraries code is an excellent way to learn a language.
I'll start off with "Real world OCaml" and see how it goes!
Browse Python projects on github and find some that strike your fancy. Especially those which may run slow, like puzzle solvers, image manipulation apps, etc. Bonus points if they have few external dependencies. Rewrite them in Rust.