231–240 of 811 posts
Rust isn't hard. Programming is hard. Rust just points out failure states before you encounter them in production.
Programming should be hard only if the problem you are trying to solve is hard. Creating an boring CRUD app shouldn't be hard. Predicting with a good degree of success the market trends for stocks and options should be hard.
Earlier quoted context omitted.
never allocating memory can be and should be simple.
What language actually makes it simple?
Earlier quoted context omitted.
I enjoy Rust, but it's not that simple. It really is more work to accomplish certain tasks in Rust than many other languages even when what you're doing is safe. The narrative that "Rust isn't hard" is getting tiresome, and I say this as someone who writes a lot of Rust. Let's be honest that Rust can be harder than many other programming languages in many ways, but those of us who use it believe the upsides and trade…
Rust isn't hard for the things you try to solve in Rust. The author compares Rust code with Go code. Those two languages serve entirely different purposes, with entirely different mechanisms behind it. Go does what the author does with ease because the runtime fixes all the complicated parts for you. You tell Go what you want and it'll try to solve all the memory management/threading/memory safety issues for you, usu…
I agree. But if you use Rust for web programming, it is fair to compare it with C# or Java. On the other hand, C and C++ feels easier to read and write, a bit more productive than Rust.
So the question is vs C# and Java: is the performance worth the pain and loss of productivity?
And vs C and C++: is the guarantees made by Rust worth the pain and loss of productivity?
I'd argue that in some cases the answer can be yes, while in others it ca be no. So, there's no universal good or bad choice, it really depends on project, team, budget and many more.
I started picking up Rust a bit over two years ago, and it was HARD. I didn't have teammates who knew it to help me out, so I used community resources (/r/rust, exercism.io, etc.) I'm still not great with the language, but I'd say I'm about as proficient in it as anything else. The progress is slow enough that you find many more opportunities to quit, but once you do become productive, I think the hard work really pa…
I'd go with 1/3 less performance by using Java or C#. While having better productivity. If we are talking a web service, of course.
Earlier 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%.
Anecdata are all I can provide, but the equivalent (Google) batch job in C++ vs. Java is often an order of magnitude better for a variety of reasons. It might only be 0.5-3x faster, but it also uses less cores and less memory to do the same amount of work.
Having written C++ and Java services, the median C++ service is performs better than the median Java service. Some of that is less pointer chasing, some of it is better libraries. Some services will be slow no matter what you write them in. There's too many variables to quantify, and "performs better" is a real load bearing term. Sometimes it's less CPU, memory. Sometimes it's latency.
I still primarily work on Java services, and they perform pretty well. That said, the operational dynamism of Java services is a real thorn in my side. Beyond the GC, there's a lot going on in the runtime including JIT that just makes JVM services less predictable. Even classloading is a source of unpredictability, unless you eagerly load classes.
FWIW, I think Go does a pretty good job being predictable too. AOT compilation helps there, you're not worrying about new tasks needing to JIT. Go mostly worries about GC (often irrelevant), warmup of state (like TCP connections), and avoiding footguns that leak Goroutines. :) At least Go's footguns rarely blow your whole leg off.
>So why Rust is so hard? Rust is a systems language. To be a systems PL, it is very important not to hide underlying computer memory management from a programmer. For this reason, Rust pushes programmers to expose many details that would be otherwise hidden in more high-level languages. Examples: pointers, references and associated stuff, memory allocators, different string types, different Fn traits, std::pin, et ce…
Maybe in C++ it's easier to get a program to compile, but it's dramatically harder to make sure you've checked all the boxes you're supposed to check to make sure your code is safe and complies with best practices.
For instance, consider the rules of 5 [1]. There are so many rules like this in C++, so much complicated stuff you're supposed to know to write anything at all, and much of this is just _accidental_ complexity: it's just there for historical reasons or language design reasons that in retrospect don't make much sense.
[1]: https://stackoverflow.com/questions/65455464/is-the-rule-of-...
Earlier quoted context omitted.
You are basically asserting that performance & correctness are beyond the reach of developers who build systems in other languages. So based on this I suppose all systems developed in other languages are either performing subpar and/or are incorrect? "Is the pain worth it" is the question. My 42 years of professional development tells me the answer is no. (I lean towards programming pleasure and not pain). YMMV.
I would say most systems are either slower or less correct, yes. The nice thing about being a developer is that these costs are mostly hidden from us. The business pays for more compute if you churn out slow code, and churning out bugs just increases your job security. Imagine if you had to pay for the performance loss or production bugs directly though...
I'm very confused. Rust is mainstream? C, C++, Java, C#, Python, JavaScript are all what I would call mainstream. Rust is not a language that comes to mind at all.
I honestly don't know of a big tech company that is happy with the idea of just continuing to use C++ indefinitely - they are _all_ looking for alternatives, and Rust is the most obvious option.
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…
I think that's ocaml. Higher level, with GC, nice type system, no traits but signatures and higher order modules might be enough for you, and a compiler that produces fast native binaries.