I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…
Elixir?
Rust Is Hard, Or: The Misery of Mainstream Programming
421–430 of 811 posts
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#422Earlier quoted context omitted.
I agree, I don't understand why so many people lately seem to want to use Rust for web domain stuff. I don't like Go, I hated the year I had to work in it @ Google. But frankly, it's better suited for 'server' type stuff, unless you're talking about a very specific type of server that has super intense latency guarantees. And now that Go has generics, I'd probably hate it less. Go is the new Java. Rust is the new C++…
>"I don't understand why so many people lately seem to want to use Rust for web domain stuff." >"Rust is the new C++. Let's just stick with that." I write "web domain stuff" in C++ and it is incredibly easy (well for me at least). In C++ I could always use my own styles / paradigms / patterns etc. etc. Not forced to any particular way. And modern C++ is incredibly safe if one wishes. So if it is bad idea to write "we…
So all in all, I really don't think that the (long-running) productivity and maintainability of managed languages can be approached by these low-level langs. And that is fine, (thank God) not everything is a dumb CRUD web app, there are very real niches where that low-level detail is a necessity.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#423Earlier quoted context omitted.
This comment right here. For most people who program for a living, the hype over Rust means little. They need to use what is in the industry right now. Often, that is a tried and true language that is relatively easy to learn and use. Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast.
> complex language which limits you Rust really does not limit you. Anything possible in C or C++ can be done in Rust if you're willing to use unsafe code.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#424Earlier quoted context omitted.
> If you can avoid async I would recommend doing so. The problem is that the entire ecosystem has completely shifted to async. There are almost no active / popular libraries related to network IO that haven't switched over. Yes. I've been complaining about async contamination for some time. I'm writing heavily threaded code, with threads running at different priorities, and libraries which want async get in the way.…
I agree, I don't understand why so many people lately seem to want to use Rust for web domain stuff. I don't like Go, I hated the year I had to work in it @ Google. But frankly, it's better suited for 'server' type stuff, unless you're talking about a very specific type of server that has super intense latency guarantees. And now that Go has generics, I'd probably hate it less. Go is the new Java. Rust is the new C++…
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#425Earlier quoted context omitted.
I like the thick stdlib in go, but it feels a lot slower even than java. The thin stdlib and giant dependency trees is my primary complaint with rust. I like most of the syntax, but async is not my threading style, I mostly use fine grained threads like rayon provides. I'm currently more excited about julia though. Same dependency hell, but super fast and flexible, and the code looks good.
You think Java and Go are slow but like Julia? It takes 2 seconds just to fire up a Julia interpreter. Its runtime is extremely heavy.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#426The "hard" part about Rust is you have to "unlearn" some of the basic mechanisms like scope and ownership that you bring from other languages. It doesn't allow you to build quick and easy solutions that allows you to lie to yourself (or your boss.) You have to spend more time upfront to compile and fix all warnings, but in my experience so far, fixing these at the right time (i.e. before compilation) is better than fixing them after someone writes a Github issue. I can't say it eliminates all bugs, but my trust level to my Rust code is around 10x more than my Python code for the same problem. (And I'm writing Python since 2002.)
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#427Earlier quoted context omitted.
Definitely not. I've been a full time rust developer for a long time now. Whenever I need to write some C# or Go or JS I honestly feel quite blind with a hand tied behind my back. I don't have the expressiveness of rusts type system and I don't have the safety of the strong compiler so I have to test my code a lot more thoroughly to be confident. With rust I'm pretty confident in my code from the start
How you feel relates to you and your preferences and doesn't really say anything about Rust versus let's say Go. Is your software more performant and does this translate to additional customers or reduced costs? Is your software more stable and does this result in reduced support costs or happier customers? Testing effort is likewise not a decisive matter. In fact it's quite likely that what one wins time-wise on the…
That said, I think Go's simplicity has a lot of advantages over Rust for a great many use-cases. Imo Rust almost feels like a prototype for a great language which will finally get ownership-based memory management right. The goals of the language are admirable, and the tooling is great, but it's such a complex language once you start getting into topics like lifetimes and async.
I think it shines for certain use-cases where the tradeoffs it makes genuinely add value, but in a lot of ways I think it's more of a niche language for people who love esoteric programming topics rather than something with the potential to go truly main-stream.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#428Earlier quoted context omitted.
No, it's a selection effect. The stackoverflow most loved metric is people_who_want_to_keep_using_the_language / people_who_have_used_it_in_the_past_year Since Rust is so early in its adoption and there are few jobs, many of the responders are hobbyists who are into Rust, like it and want to keep using; not necessarily people who use it for work. And since you only take into account the people who have used it in the…
IMHO it would be good for Rust to become popular niche/specialist language for systems programming. Currently Rust is not as complete or well defined as Ada/SPARK or MISRA C/C++ combined with commercial analyzers (Astree for example). At the same time Rust is "too sound and rigorous" for mainstream programmers. Rust advocates are in the losing battle of of forcing mainstream to adopt "it does not compile unless compu…
Gotta say SPARK does seem to provide much of what it claims. Interesting that NVIDIA seemed to be using it for their secure bits.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#429Earlier quoted context omitted.
Why? Because it's stupid fast, fast means serving an order of magnitude or more clients before requiring scale up. Scale up means $. No stop the world GC time situations, etc. That's basically it. To be fair, I usually prefer to use go as well, lately though rust is more appealing.
It's at most 50% faster than Java and C# and not faster than C++. An order of magnitude would mean 900%, not 50%.
Re: Rust Is Hard, Or: The Misery of Mainstream Programming
#430Earlier quoted context omitted.
I'm pretty sure "fearless concurrency" is just a meme at this point since Rust does very little to make concurrency "fearless".
There are two kinds of threading bugs: deadlocks which are easy to detect and race conditions which are far more difficult to detect and to fix. AFAIK Rust helps with the latter not with the former which is a very big improvement (much more than if it was the other way round)