We’re getting in a Rust vs other languages here. The main post was about
what is the best way to learn Rust, not what is the best programming
language. But I’ll still put my two cents since we’re already here:
But we also shouldn’t prematurely optimize performance at the
expense of much greater development costs
Well, it depends. I don’t see my Linux Kernel being written in something
else than C.
I wasn’t discussing special situations such as kernel-writing. I was
talking about the tendency to view Rust as a general-purpose language for
application-writing. I think its use in many of those settings is not
justified, because its benefit is not needed (performance) and so it
doesn’t make sense to pay the additional cost in development time vs. less
And dev. cost is relative. Let’s take the C example: it’s great for
performance and maybe faster to write because you don’t fight the borrow
checker or lifetimes. But SEGFAULT is something you will see a lot. What
I’m trying to say is that money will go into debugging. And C has been out
for 45 years! Rust for only 7. Maybe in 10 years those concept will be
widely used and understood, thus reducing costs. (Keep in mind that this is
what I think)
I’ve written an awful lot of C over the years and debugging is just not the
problem you portray, at least in my experience. The tools are awfully good
– gcc, clang, gdb, valgrind, etc. and the language is simple, easy to
understand, and extremely well documented. And you have to weigh the time
to find the cause of a segfault against the time required to make the Rust
compiler happy, which can be considerable, especially when you get into
obscure borrow-checker and/or lifetime errors.
I do agree with your point, though, that as time passes the Rust compiler
will get better and so will the documentation, resulting in less
head-scratching when using the language.
I would also argue that there are applications where dynamically typed
languages – Scheme, Python, Ruby – create more of a debugging headache
than C (or Rust or Haskell), because things that the compilers would catch
don’t turn up until runtime and sometimes not exactly where the problem
occurs, depending on how much runtime checking is enabled. Unbound
variables, perhaps due to typos, are an example. So if you have an
application that requires a fair amount of runtime even when testing, the
edit-debug cycle can become quite long.
Look, the point of my initial comment was not to denigrate Rust. It’s
simply a matter of choosing the best tool for the job at hand. I get the
feeling that some are so in love with this new technology that they want to
use it for nearly everything, ignoring more suitable tools in some cases.
There’s an awful lot of perfectly good software
out there written in interpreted languages
There’s also a lot of software
out there written in C++ that shouldn’t have been, because the performance
gain serves no useful purpose, but the projects took a hit in development
and future maintenance costs.
This is what I would call: bad choices.
For example, I always had in mind that Java is slow. Yet, all of
Jetbrains’ IDEs are in Java and now moving to Kotlin piece by piece. Seeing
benchmarks for Java vs C++ there is a big difference, but they decided to
stay on Java.
I don’t think the cost-benefit proposition justifies using Rust for most
userland applications.Said another way, most of those applications will
function just fine in an environment with memory managed by a garbage
It does where it matters. Where safety and speed is really important. I
don’t want my web browser to be slow and have a lot of issues since almost
my entire life is on the thing.
But the choice isn’t either write it in Rust or it will be slow and unsafe.
There are other languages that provide good performance and memory safety
and are easier to learn and write than Rust.
But Go and Haskell offer the same static typing advantages, without the
tyranny of the borrow-checker and the still-not-adequately-explained
The borrow-checker is something that you get used to by programming in the
language. I find myself fighting it very often, but when I’m done fighting
it, it works.
Sure, it works. But at what cost in time? You always have to weigh the cost
against the benefit. You could write the same application in assembly
language and eventually get it to work. Would it be worth it?
And lifetimes, as I said before, are a new concept. At least it has some
kind of documentation and help online.
This is an area where I think the documentation is simply not adequate. It
may be so because the lifetime rules are so complex. Just go through the
messages on this forum related to the lifetime issue and you will find a
lot of confused people.
Just to leave here too, the community is a very disregarded aspect of a
language. It seems like it doesn’t matter to some, but for beginners, the
Rust community is insanely good and I would consider it as a part of the
language. If you have any issue of any complexity, leave it here, give it
some hours maybe and you’ll have a detailed answer proposing many options
for you to use and in which situation.
I agree with that completely. Without that help, I would not have gotten
the ported applications I spoke of earlier working.