Part of a new series! Feel welcome to dip in and weigh in on a past question.
Let's say I've never used Rust before. Can anyone give the run down of what the language does and why you prefer it? Feel free to touch on drawbacks as well.
Part of a new series! Feel welcome to dip in and weigh in on a past question.
Let's say I've never used Rust before. Can anyone give the run down of what the language does and why you prefer it? Feel free to touch on drawbacks as well.
For further actions, you may consider blocking this person and/or reporting abuse
Larger ecosystem than Haskell and Scala, embracing some similar ideas about type systems and some elements of expressive/functional programming. I would use rust instead of Haskell, Scala, or OCaml only because it's ecosystem is larger.
In an ideal world, one of the functional languages would have a huge ecosystem and rust would only be used for extreme performance and low level tools. At present, I would use rust for high level web programming as well, if I wanted to use Haskell, but I wanted as many libraries as golang or python. Rust might match golang's ecosystem size within three years.
Not larger than Scala. With Scala you can use anything JVM, which still is more/better in a lot of cases than Rust IMHO.
True. I usually only evaluate an ecosystem based on its native libraries, so I exclude java libraries when evaluating clojure, etc.
Yes - Rust embraces a LOT of FP concepts, but in a less "extreme" way than Haskell ... still waiting for FP to go mainstream, will it ever ... ?
With 80k packages, I think rust's flavor of FP is the closest to mainstream that functional has ever reached on the backend. Scala had a shot, then faded. Clojure just hasn't broken through. Elixir isn't breaking through.
I agree with you, seems Rust is the closest thing to FP (or a variant thereof) going mainstream :)
Its a programming language with re-imagined programming paradigm.
Here is what I mean,
C is great language that was created about 50 years ago. So asynchronous calls, sugar-syntax, generics, were all added to the language when there was high demand for it. There are many attempts to create a language that is basically update to C. Like zig, nim, D, C++, All these are languages that are trying to improve C
Rust is not trying to be incremental update to C, It is a language that was created after analyzing 50 years of history of C. It is not trying to be a better C, it is a separate language that has learned all the caveat's of writing safe code, and implemented it as a core language structure. Writing safer code is not a coding practice, its only way to code.
Instead of talking about allocation of memory (which nowadays is handled by api hooks in kernel and ssd/hdd drivers) we talk about ownership of that memory block, This makes more sense in modern computing world.
In traditional languages, it is a safer practice to make sure your variables are immutable as needed. But in Rust, variables are immutable by default, and you need to make it mutable if you need it to be. Strings didn't exists 50 years ago, it does now. Co-routines were only usable if you had multi-core processor, but now, multi-core processor is ubiquitous, so it makes more sense to design the language with lambdas and asynchronicity as a first class language feature. Switching to safer defaults instead of reliance on developers knowledge to write safe code allows for a more secure ecosystem.
But most important feature of modern languages like elm, kotlin, rust; over traditional languages like js, java, C; is the first party tooling around it. Code formatting is not a 3rd party tool someone wrote based on his opinion, it is provided by the people who created the language, making sure that new formatting rules is available from day 1. Documentations parsing, bundling and packaging tools, job runners, informative errors, error sniffing and fixing, these are all available with the language itself. We don't have to wait for some 3rd party lsp, to catch-up to new language features.
It is a bit rusty. Me IRL:
You certainly don't want rust's borrow checker cause irreparable damage to your self-esteem by condemning your code for doing stuff that would be perfectly normal in other languages even though it might potentially create memory leaks. You don't need lots of different types of strings that each perfectly fit a different use-case, let alone a multitude of small APIs that each only does one job extremely well. You don't want asynchronous handling just be a stub that you can fill with whatever library you just want, depending on your use case – nobody needs that much control! Not to forget that the incredible performance benefits of the language are basically completely negated by the time the compilation requires. Also, everything gets statically linked, which somewhat increases the executable size; granted, those are still reasonably small. And you're a professional developer, you don't need the WASM target that produces really tight code. Long story short: you don't want Rust, unless you do, do you?
I disagree definitely because a rust program typically uses less power, is more performant and most importantly has less issues than C or C++ programs. With wasm you can create smaller and faster web pages which require a lot of content, what’s your point here?
I should have probably marked that as sarcasm, but I thought it was obvious.
The only cons is that sometimes writing something which would be trivial in C++ for example takes much more time in Rust but it's worth it most of the time.
When I worked on a larger mono repo consisting of numerous libraries wrapping java libraries for use in scala, it felt like each scala wrapper was almost half the work of writing the full library from scratch (exceptions -> either, making mutable api's more immutable, etc). I got the same feeling with rescript and wrapping javascript libraries. The imperative platform libraries don't really save much time in the way that a native library does, it just reminds you of how much work is left to flesh out the ecosystem.
I think borrowing should have been lending. It runs on just about everything, including IoT devices. You won't be an idiot forever, but you might have moments when you are sure you've had a stroke because you can't quite grasp things immediately.
I came up the C/C++/C# path and find it to be rewarding. Memory handling is controllable in small spaces.
As others have said, the community is welcoming. Even on reddit. Er, especially on reddit.
I've not learned it, but I'm thinking of switching my efforts on learning Golang towards Rust because the performance benefits are similar but I hear more enthusiastic things about the community.
I'm learning both. Have to say Go is easier to learn, I've also come further in my journey, i.e wrote a free book :) leanpub.com/go-from-the-beginning. Rust is slightly faster, I like it too.. So there seems to be more Go devs in the world but the community for Rust seems more enthusiastic, I agree with that :)
Just got the ebook, I'll definitely start reading it this weekend. Thanks for writing and sharing it!
any time :)
Rust community is amazing, and although it's harder, it's well worth learning it. So I would say don't give up on Rust easily! If you like it, keep going.
Do you like being beaten into submission by your compiler until you get it right, thats rust as I know it 😊
"beaten" is a bit harsh. The Rust compiler error messages are super nice :D
Oh yes they are, okay politely beaten because I still get a headache working out lifetimes and all that, I'm a bit rusty so perhaps ignore my out of date opinions before I get egg on my face
haha politely beaten is a good way to put it
Rust is amazing. I made a huge refactor in my library, fixed all compiler errors, and the code just worked. Clear error messages and Rust's strict typing makes this possible.
Rust syntax is clean. In most other languages, I always find syntax to be to some extent arbitrary, but in Rust, the syntax feels intuitive as if they've thought of all possibilities and truly found the best one. Its module and trait systems are pleasant to work with and reduce code ambiguity.
Tooling is official, comprehensive and makes life significantly easier. Rust analyzer, the official language server and IDE integration; Clippy, Rust's official linter; cargo, Rust's official package manager - they are very high quality tools. Both integration and unit testing is built into the language and pretty much what you'd hope for. It's trivial to add a dependency and publish packages.
I also built a macro for my library - it had to parse Rust code passed inside it and transform it. It was a breeze due to the currently existing ecosystem and ended up being under 100 lines.
It is fast, has the best Web Assembly support, thread and memory safe, disallows undefined behavior and segfaults. It automatically manages memory for you without an overhead of a garbage collector. It has great, thriving, evolving and enthusiastic open source community. Rust makes anxiety-free systems development accessible to everyone :)
It's fun! Modern syntax features. No fighting with setting up environment. Everything in cargo (format, dep management etc). It's fast.
The logo is cool 🦀
Haha okay, yes you're right, if it was ever gonna happen then it would have happened already ... maybe FP, for all its touted virtues, is just too different from how the MAJORITY of us are thinking ... people who "grok" FP love it, but the transition is probably just too big an ask for most of us (or we just don't believe it's worth the effort).
The funny thing though is that in the JS world (and in other languages) the map-filter-reduce paradigm has become hugely popular, so then you'd think, why not take the next step, and "go FP" - kind of amusing that only these 3 "all time favorites" are being cherry-picked, lol ...
Fp-ts exists, and the people who end up taking interest in it, probably leave for rescript, elm, or haskell. I don't think fp-ts will grow significantly beyond it's current audience. The only potential within backend javascript/typescript is a slightly stronger emphasis on higher order functions, immutable values, and a deemphasis on OO, but I don't expect that to develop into richer functional programming.
Rust has big corporations advertising use now and huge developer momentum. If something like fp-ts or some important frameworks within rust push on using the full spectrum of functional programming concepts, then I think it has potential to make as much an impact on backend as react did on front end functional.
Fp-ts gcanti.github.io/fp-ts - interesting ...
So you're saying Rust is (or is becoming) a "next big thing"? And for development of what kind of applications are those companies hiring - embedded, network apps, backend web, frontend web with WebAssembly?
I don't think it's a next big thing. I think it will continue replacing c, possibly get traction with wasm, but I see people who like haskell or scala reaching for rust for backend web, and I expect that segment to continually grow because backend web is everywhere and typed functional programmers have to make a living doing something. Maybe one of them will detour and create something like servant, but with a lot more developers actually paying attention.
If your rust code gets compiled, you can bet it won’t crash.
I would use it to optimize/extend other languages instead of relying on C/C++.
It's awesome when used on the right project.
Rust is not panacea
drsensor ・ Feb 24 '21 ・ 1 min read
For monolithic and/or monorepo project with decent number of dependencies and macros, CI caching and distributed build system might be necessary. Single PC/laptop is not enough. Work best when combined with sccache + Nix caching service like cachix.org or garnix.io
RUST RUST RUST RUST RUST RUST RYSTTTTF
anyways on a serious note, blog.dhravya.dev/learn-rust
Similar to C/Java, has tuples, has arrays, has vectors, has fucking 128-bit numbers.
It's pretty good.