🦀 Blew it on Rust. Unexpected finale 🦀
I was writing more and more posts on the topic of what I don't like about Rust, until at one point I realized one very simple thing
#whyrustwhy #rust
# [ $davids.sh ] · message #204
🦀 Blew it on Rust. Unexpected finale 🦀
I was writing more and more posts on the topic of what I don't like about Rust, until at one point I realized one very simple thing
#whyrustwhy #rust
@ [ $davids.sh ] · # 879
As I opened each new topic in their guide, with each new page my eyes bulged so high that by the middle they were practically on my backside.
And I kept writing and writing my confusions until I realized I didn't like anything, except for pattern matching, lifetimes, traits, and borrowing (the last 3 are complex, but justifiably so).
And then it hit me: I just had the wrong expectation.
I'm looking for a more convenient alternative to C, and ideally an alternative to Go, but with memory management.
These are powerful languages, with strict boundaries and minimizing "magic" to the bare minimum (C isn't quite like that, but you'll understand what I mean later).
I've always loved the concept of "do 1000 things 1 way," rather than "do 1 thing 1000 ways." That's what distinguishes Python from Ruby, C from C++, Go from Node.js.
And Rust is precisely about the ability to "do everything and however you want."
Rust is closer to C++, but with built-in functionality and a unique approach to memory management.
And from this perspective, Rust is an amazing language.
When I looked at my list and code with this new perspective, I realized that it had done everything absolutely right.
It's just that I hate "however you want," I hate the lack of strict rules and boundaries, I hate C++.
So, if this doesn't bother you (and maybe someday it won't bother me either), then Rust is an awesome choice.
If you're interested in hearing what bothers me about this approach, then leave an emoji. Once I get 10, I'll continue, but in the format of "I want a child of Rust and Go with / without these features."
@ [ $davids.sh ] · # 880
And a definite advantage of Rust:
And yes, in the second case, you'll take longer than with Go, and you might mess up and make Rust slower. But with experience, I think the speed evens out, and you can optimize much more finely in Rust, so sooner or later the program will definitely be faster.
And thus, Rust also becomes a good option for web development (and C and C++ don't even come close here).
@ [ $davids.sh ] · # 881
BUT ONCE AGAIN, I will still primarily prefer Go for IO-intensive applications and applications with business logic.
Rust here is more like an opportunity to stay in a monorepo and not shoot yourself in the foot.
@ [ $davids.sh ] · # 882
And also, Bevy is written in Rust – an ECS framework for game development.
And its coolness lies in the fact that:
– It's as fast as C++ engines, but much less of a pain to work with. – It's written in Rust, and its source code is part of the game you're writing, so you can always see the specific functions you're calling and change the flow. – It also has a built-in plugin system that allows you to change almost any aspect of the engine. – And it has a proper ECS out of the box (but that's just me being a fan of ECS and Data Oriented Design in general).
I'd love to see Bevy evolve into a Godot-like engine (with UI and all that) someday.
@ [ $davids.sh ] · # 883
And the entire ecosystem of JS tools and WASM is completely flowing into Rust, which really gives a breath of fresh air, speed, and quality.
Why? Again, because such things would have to be written in C++ to have "all possibilities," but C++ is difficult and already unpleasant to write.
But Rust is just right for this.
@ Arsen IT-K Arakelyan · # 886
Could you write a post about why the "do one thing 1000 ways" approach is bad? 🤔
In general, I understand, of course, because excessive flexibility and freedom lead to problems, and therefore people will prefer to solve problems not correctly, but as easily as possible, and this is often worse in the long run if you are doing something big.
That's why Node.js is more popular than Go, and Express is still several times more popular and downloaded more often than Fastify.
Because it's much easier to get started. Make an MVP/PoC, then throw it away and rewrite it in something normal/stable, like Java/C#.
But isn't the super flexible approach preferable for professionals, as it allows for a much more nuanced and custom solution to the problem in the end?
The approach is probably bad for the platform, community, and industry.
@ [ $davids.sh ] · # 887
Overall, you described it correctly.
A few comments:
. "on something normal/stable, like Java/C#" – I've rarely (if ever) seen rewrites from Node.js to Java/C#, unless the reason is "our main team is Java, so we write in it."
If you can build a working prototype in Node.js and want something more advanced, that's exactly what Go/Rust are for. If something requires Java/C#, then it doesn't make sense to write it in Node.js in the first place.
But this is a heuristic.
. "approach is super flexible and more preferable for pros" – most likely, but I have a hypothesis that a language hasn't appeared yet that takes C, removes all the bloat, adds simple parallelism and concurrency, normal memory allocations, and at the same time becomes popular.
I'm looking at Zig precisely because it currently needs to solve the concurrency issue and continue to gain popularity.
There's a good chance it will become the language that C programmers start migrating to (because it's almost 100% backward compatible), and this will prove that you don't need too much flexibility and magic.
@ [ $davids.sh ] · # 888
But I'll tell you more in a separate post
@ Arsen IT-K Arakelyan · # 889
Thank you, I'll be waiting)
@ Vassiliy ITK Kuzenkov · # 1243
Actually, there's another good contender for this title in the future - Odin. https://odin-lang.org/ The language is much closer to a symbiosis of Go and C. It's used in a couple of large VFX projects in cinema, including in real-time. https://graphitemaster.github.io/odin_review/ Here's a good review of the language (including its downsides), and another one from Anton Ziyanov https://antonz.ru/trying-odin/ (more complimentary).
@ [ $davids.sh ] · # 1244
My palms started sweating from the first three points 😍
And also "Data oriented language"... sounds divine