I thought it was a great way to get introduced to Rust, especially when concurrency comes into play. Having only ever written this sort of code in C/C++/Java, the way Rust required me to rethink my design to properly incorporate its concurrency model was really interesting to me.
For some reason sharing "references" in a formal way felt a lot different than what I was used to, and I'm not sure why. I'd say I prefer it, perhaps because it made my design feel more deliberate.
Rust is getting more attractive everyday, I wonder if there is something about the language that highly influences lib authors to write quality stuff or if the community has a high ratio of experienced devs.
IMO all the “fighting with the borrow checker” stuff is overblown. If you do get some complaint from the compiler, it is usually very easy to fix.
Moreover, rust is very expressive. The functional facilities coupled with combinators make the language very ergonomic to use.
I use the language for almost everything I can. If it’s something that would normally be a quick script, I will still reach for rust but not be very constrained.
If the project turns into something more it’s easy to refactor and decrease memory usage etc. Testing is kind of a “first class citizen” so that plus “compilation driven development” make it a pretty hackable tool.
My one caveat is that I'd say rust is a language best to pick up after you're already a polyglot with a few years of experience in several other languages. It uses so many ideas and concepts from several other paradigms that I think it helps an unusually great amount to have a polyglot background coming in.
I have replaced all my tooling with Rust, fwiw. Rewrote several things at work with Rust (which started this train for me lol), and now all my projects are in Rust as well.
I often say that Rusts complexity is oversold (by myself, too, at times), and it can be just as productive as Go, if used like Go. That is to say, Go is often touted as being hyper productive because it takes decisions away from you, such as Generics. You can apply the same tools to Rust, and suddenly you lack a ton of features but also reduce the possible roadblocks you might be wanting to avoid.
Personally I don't even avoid any Rust features these days, I use all of them (that I understand, at least lol.. which I think is all). I more productive than in my Go days (~5 years in Go, fwiw).
LSPs are great :)
: I switched to Atom for non-Rust reasons. Boy do I miss Kakoune every day haha.
A lot of people seem to really enjoy the IntelliJ Rust plugin.
Memory management aside: compilation-time guarantees of your code is probably the best thing about the language.
Prototyping ideas is great in Rust, since it's compiler/type system are a nice pair of helping hands.
I will say, a proper first class REPL would be nice. Maybe some day.
Agree. I tried to prototype in Python, but even with great IDE support it's hard to manage constant refactoring when you're moving fast.
I write C at work: to me Rust is fun for playing with a more functional style. The type system makes refactoring easy when I mess up. The tooling is good and the answer to 'why is thing X like Y?' is rarely 'because of legacy'.
It could serve as a great second or third project for someone learning rust and the rust-ecosystem.
I think building such a compiler would impractical, because in C, you can turn a pointer into an integer and back again. While it's an integer, you can hide it in ways that would make it invisible to a garbage collector. For example, in a xor linked list:
(it's really a little more complicated than that in codebases, like mysql, that probably manage their own allocation and actually care about page level stuff)
I'm not really sure what you're expecting. Haskell gets a vastly disproportionate amount of time here compared to it's actual usage also, and PHP gets almost no coverage at all, but we all know it's out there in force, and so are the people that program it. Should we be pushing for a lot more PHP content? What about COBOL content? That's still in use, and I can't remember the last time I saw a submission about that.
In Python Paradox, the author argues that it's a signal of quality that someone would take the time/effort to learn Python. (Python is new and wouldn't land them a job).
Now in 2019, Python is popular. But I think it's fair to say instead that Rust wouldn't be a good choice if you wanted to get a job using a language which is popular in the industry.
1. I want to add a low(er) level language to the ones I already know and use.
2. Though I did some C/C++ in high school, getting really into depth with C++ at the moment seems really daunting.
3. I don't need it for a job at this point so I can afford to learn a less popular language that can potentially have a future and which exposes you to new ways of thinking about code.
In my case with the devs I hire the only thing I care is that they want to work in a class of languages, like frontend or backend, and that they're not super picky.
I'm hiring people to solve problems for a living. I have full confidence that anyone I hire can learn any language I throw at them. My job (when hiring) is to make sure they'll want to work in the area, maybe a footnote about the language (if even known), but that's all.
Why does language matter so much to some people (as far as hiring goes).
Do you have some particular animus against Rust, or do you think it's some sort of general rule that developers should learn only the 'top 5' 'industry' languages?
I've started learning Rust, for a few reasons:
- I read a couple of chapters of Steve Klabnik and Carol Nichols' excellent "The Rust Programming Language" a while back and enjoyed it so much just as a book that I promised myself I'd read the whole thing when I had time. Now I do, so I am.
- Rust instantiates some concepts that I'm familiar with but only at a vague hand-wavy level. Learning it is educational (for me).
- Rust is used in some open-source projects I'd like to contribute to if I can.
- I have a couple of personal project ideas in disparate areas (wasm, embedded) that Rust seems well suited for
It's quite likely I'll never use Rust in a job. So what?