Or even better, if both is the same. That's the reason why, as much as I like Rust, I would never use it for a project where performance is not critical.
That makes it just less transparent. You still have to be
careful and know the difference or one day you unintentionally
create a shallow copy of an object and now you've got a bug the
runtime won't warn about. Yes, Rust is more complicated and
harder to get into in those areas, but in return it's not as
ambiguous. I know that calling `clone()` will always do just that,
no edge cases, and even if I were wrong the compiler would
immediately tell me because of a type mismatch.
Realistically I don't think any of the two approaches is
significantly faster. But I know what I find more consistent and
less frustrating to debug.
You are talking from the perspective of Rust. And you are right that in Rust, it cannot/should not be the same!
However, if you forget about Rust specifics, then things look different. E.g. by simply having the constraint of complete immutability, there is no reason to differ between an object identity and its deep content anymore - it will just be always the same. Of course that means no mutation and hence reduced performance for certain things, which is why Rust doesn't do it.
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.
That makes it just less transparent. You still have to be careful and know the difference or one day you unintentionally create a shallow copy of an object and now you've got a bug the runtime won't warn about. Yes, Rust is more complicated and harder to get into in those areas, but in return it's not as ambiguous. I know that calling `clone()` will always do just that, no edge cases, and even if I were wrong the compiler would immediately tell me because of a type mismatch.
Realistically I don't think any of the two approaches is significantly faster. But I know what I find more consistent and less frustrating to debug.