Rust is absolutely amazing and made me a much better programmer. But programmer ergonomics don't seem like a focus of their team currently.
I can only hope for Rust 202X edition that can introduce new syntax / deprecate another and make certain things clearer (even if that means explicit with a little writing here and there). Lifetimes and traits in particular need a lot of upfront investment to grok intuitively, and the fact that some core aspects of the language are implied can later hit your assumptions really hard and confuse you for a while. At least that's happened to me, maybe I am just dumb and mediocre though.
> But programmer ergonomics don't seem like a focus of their team currently.
Actually, maybe my post gave a wrong vibe. I like Rust and I think the team put a lot of effort into programmer ergonomics.
It's just that the language is focused on performance a lot and compete with C++. And so they sometimes make tradeoffs in favor of performance instead of expressiveness or simplicity.
That is understandable - but 95% of the projects I(!) have worked on don't need this - I can just give it a GB more RAM and a bit more CPU and write software quicker because I don't have to care about certain details.
> At least that's happened to me, maybe I am just dumb and mediocre though.
The fact that you used Rust probably puts you in the upper 10% - rough gestimation. I'm not telling you which 10% though. :P
> It's just that the language is focused on performance a lot and compete with C++. And so they sometimes make tradeoffs in favor of performance instead of expressiveness or simplicity.
Yep, exactly my feeling. When I get back to writing Elixir at my $day_job I am just blown away how I can achieve most of the same results (for 100X less performance of course) in like 20x less coding lines... :( Not a direct comparison with a dynamic language is possible of course, but I too wish the Rust team starts sacrificing something for a bit more expresiveness and code conciseness.
> That is understandable - but 95% of the projects I(!) have worked on don't need this - I can just give it a GB more RAM and a bit more CPU and write software quicker because I don't have to care about certain details.
Both what you describe and hand-crafted and ruthlessly tested C/C++ code that's maximally efficient have their place. But I definitely don't belong the the "machine efficiency at all costs" tribe and I get worried at any potential signal that Rust is headed in that direction. Which it might not be. We'll see.
> The fact that you used Rust probably puts you in the upper 10% - rough gestimation. I'm not telling you which 10% though. :P
<Saruman voice> YOU HAVE NO POWER HERE!
...I mean, I am myself's worst critic. It took me a while to get comfortable with Rust and even if that means I am a below-average programmer, I don't care. I am taking my time and I can objectively measure that I am getting better with time there.
I still do agree that Rust does require time and persistence however. That is irrevocably true. Here's to hoping the team will make it consume a bit less characters (and thus typing) and improve the compiler and the tooling further. I am rooting for them with all my heart.
> I get worried at any potential signal that Rust is headed in that direction. Which it might not be.
I think they do - but that's good! We need a language like Rust to write operation systems, databases, proxys, webservers, hey maybe even browsers. All the things that are widely used and need to be high performant and secure.
Maybe you are using Rust, but you actually really want a different language, one that doesn't focus so much on low level / performance?
Haskell or Scala or F# come to my mind. I'm listing statically typed languages, because I assume you like those (otherwise, why Rust and not sticking to Elixir).
> Maybe you are using Rust, but you actually really want a different language, one that doesn't focus so much on low level / performance?
That is very possible. But utilizing my experience and intuition, very rarely have I seen such meticulous and relentless pursuit for efficiency and a compiler that will kill most of your bugs after it successfully compiles your program like Rust. Maybe Haskell and OCaml are it as well but they have plethora of problems that Rust doesn't have. Maybe Nim and Zig? Only heard good things about those but never tried them.
> Haskell or Scala or F# come to my mind. I'm listing statically typed languages, because I assume you like those (otherwise, why Rust and not sticking to Elixir).
Personal / professional development. I started with C/C++ and Java 19 years ago and moved to dynamic languages at least 12 years ago and I felt that I want to have such a powerful language like Rust in my toolbelt again.
I would say Haskell does a much better job but at the cost of much harder to predict performance.
Scala (which I use professionally) comes close to Haskell, but you need more discipline, because it has e.g. the concept of "null" and you have to avoid it.
What I like about Scala is that it has a sweet spot in the sense of a good number of jobs (way more than Haskell or Rust) and also having very good tooling (better than rust, not as good as Java though).
And Scala gives you this "if it compiles, it works" feel. But it has a steep learning curve.
I think F# is also great and underrated - same for OCaml. But because the languages are even more niche, they have less good tooling etc. What plethora of problems are you referring to btw?
Nim sounds exciting, but I've never used it either.
> I felt that I want to have such a powerful language like Rust in my toolbelt again.
If you are up for systems development, I would stick with Rust tbh. I think it will offer you some good job opportunities down the road and in general have a bright future. I don't think other languages like C++ or D can really compete with Rust in the long term.
Otherwise, I recommend to Haskell or Scala a try, depending on if you favor the learning experience or the practical gain.
> What plethora of problems are you referring to btw?
- Haskell: literal hundreds of possible combinations of compiler variants. Immediate turn-off.
- Haskell: several String types. I understand the lazy / non-lazy distinction but I can't understand why in 2021 you have C strings and UTF8 strings separately. I am not seeing much Haskell adoption in embedded contexts where every byte counts. Felt like a meaningless academic pursuit and not a practical concern.
- OCaml: lack of actual parallelism. I am following the Multicore OCaml monthly reports but at this point I accepted that it's best to just wait for OCaml 5.0 which promises it will have Multicore baked in (earliest timeline: end of 2021, so I don't know likely mid-2022?). Also I don't like the mixed paradigms. Even if I would appreciate using a `for` loop every now and then I think I shouldn't be given that freedom. But that last one is a minor gripe actually.
- OCaml: strings again. Having UTF-8 strings there is a challenge. In 2021 there is absolutely no excuse to introduce friction on such topic. UTF-8 strings must exist. I know I can use the libiconv bridge and it's not what I am talking about. I am talking first-class support.
- Haskell and OCaml tooling felt behind excellent tools like `mix` (Elixir) and `cargo` (Rust) but I hear that they are constantly improving and are easier and more intuitive these days. Hope my impressions are outdated there!
There were others but I only managed to remember those above.
Ah yeah, the Haskell problems you mentioned are indeed annoying. However I think the compiler extensions are actually not a bad idea. Haskell is an old language and the extensions allowed it to improve over time.
Languages like Rust or Go will find themselves in a spot where improving the language will become hard - same for Java and look how slowly the language improved and improves still.
Can't say so much to your remarks about OCaml, but was interesting for me to read.
Mostly because I don't feel they will teach me something new. But I might be mistaken, who knows.
Another factor is the so-called T-shaped skills. I feel I've been going wide (learning every possible technology and paradigm under the sun) for waaaaaaay too long. I now want to focus on several skills and learn them to near perfection before going wide again.
If you already learned pure functional programming through Haskell, then I would not recommend to learn Scala to broaden your overall language-skills.
If you haven't really done the pure functional programming thing, then I recommend to learn it. Especially the way of doing concurreny would be very very different from how it's done in both Rust and Elixir. Scala also has actors, but the other way of doing concurrent programming is more interesting. For example, check this here: https://zio.dev/docs/datatypes/datatypes_stm
This is something you don't have in Rust or Elixir at all (to my knowledge).
But if it's really just for the sake of learning, I think choosing Haskell is better - who cares about strings when you learn these things.
If you want to specialize, learn Rust in and out. :D
Yep, I've been quite exposed to [almost] pure FP for 4 years and something now -- by working with Elixir. Definitely not as hardcore as LISP or Haskell but I feel it already made me much better than before. So in terms of being exposed to new programming / comp-sci paradigms, I don't know, I am sure I haven't seem them all (stuff like Coq and Idris 2 comes to mind as an example) but I also don't want to only invest in being a walking talking (and useless) encyclopaedia. :)
> This is something you don't have in Rust or Elixir at all (to my knowledge).
Maybe I am misunderstanding you but Erlang -- and thus Elixir -- has the best actor system invented so far. Message passing, copying data between actors, immutability, Erlang's OTP (fault-tolerance and tunable restarts of crashed actors), all of those things were the entire reason I moved my web work to Elixir at all. Well, the amazingly well done build and task executing tool `mix` turned out to be a huge and pleasant bonus, not to mention the very welcoming community and top-notch docs and best-I-ever-seen REPL experience.
In fact Erlang's actor system is so good that those in Scala and .NET were very heavily inspired by it. Akka in Java land as well.
Rust is getting there too -- the async semantics, the const functions and the various runtimes definitely are converging to much more efficient and machine-native actors with zero copying semantics and dynamic multiplexing on all CPU cores. I am extremely excited to see where Rust is headed in the next 5 years. It has the potential to get very close to the end-all be-all language.
> If you want to specialize, learn Rust in and out. :D
Completely agreed! There's so much work to be done out there that requires efficient use of hardware. So many companies have legacy systems still limping on ancient C/C++ monoliths and 2-3 brave souls are maintaining them, but the business wants either new features or the tech debt is preventing any improvements -- reasons abound.
Rust is extremely well-positioned to disrupt a lot of companies with legacy systems. I am planning to cash in on these opportunities. So it's a good advice from you, thank you.
> Maybe I am misunderstanding you but Erlang -- and thus Elixir -- has the best actor system invented so far.
I would sigh off on that, and yeah, I think you misunderstood me.
> Yep, I've been quite exposed to [almost] pure FP for 4 years and something now -- by working with Elixir.
That surprises me. I'm not sure we use the same terminology. There is no "almost" pure. Immutability and passing around functions is nice, but it is really only 10% of functional programming. Mind that many languages call them "functional" nowadays, but the original meaning is actually different - it's about referential transparency. I'm not aware that Elixir supports that in a meaningful way, especially since you said you did it for 4 years.
So for what I'm writing next, I'm just assuming that what you did is using immutable datastructures and avoiding mutation of variables etc.
If someone comes to me and wants to learn actorsystems, I can direct them to either Erlang/Elixir or Scala (with Akka). But honestly, Scala+Akka makes it difficult to fully embrace actors and is just... inferior. I would always recommend Erlang/Elixir and would even go so far to say, that most people probably don't really learn to think in actors if they pick Akka.
For pure FP however it is the opposite. If you have not written any slightly bigger program in Haskell or Scala using FP, then you also haven't understood the concept. If you don't already think in pure FP, then you will have a hard time to learn it when writing Elixir.
In Scala, the situation is much better, but still not optimal _for learning_ pure FP. I suggest you to look into Haskell again when you feel in the mood to tease your brain a bit with a new style of programming. Pure FP is as different from using Elixir/Actors as Exlixir/Actors is different from writing python. You have to think different.
For me, both Actors and oure FP are actually techniques that complement each other very well. Pure FP is good for writing all the code _inside_ of an actor. It makes reasoning and concurrent programming much easier compared to having a lot of really small actors. On the other hand, pure FP does not scale - once you cannot stay in your own small "bubble", you need a concept to go beyond. Be it to work with multiple machines, deal with elegant recovery from hardware problems or network problems between bigger parts of the system, or simply load and messaging problems. I don't know anything that is better suited than the actor model here. I hope that eventually we will have a VM like the Erlang VM with a language that supports pure FP as well as Haskell does. :)
I can only hope for Rust 202X edition that can introduce new syntax / deprecate another and make certain things clearer (even if that means explicit with a little writing here and there). Lifetimes and traits in particular need a lot of upfront investment to grok intuitively, and the fact that some core aspects of the language are implied can later hit your assumptions really hard and confuse you for a while. At least that's happened to me, maybe I am just dumb and mediocre though.