Some projects are written as explorational prototypes or MVPs. I don't think anyone is saying Rust is much good for those.
But (numerous) other projects are written as "the first real Quality implementation of [well-known problem], using a decade's experience with other implementations." Much of the common software we use—{server daemons (HTTP, SSH, DNS...), parsers and encoding libraries (for XML or JSON; JPEG or PNG; MP4 or MKV...), databases, load-balancers, distributed queues, ...}—fits this paradigm.
If you're writing Nginx, or Redis, or djbdns, you aren't "adding features" out of some agile user-story kanban; you're carefully implementing a small, curated set of well-known, well-understood features, with much research done to ensure that you arrive at the best and least fraught implementation, the one that will make people prefer your software for its quality and reliability and set-and-forget nature.
Rust is for that kind of software. (Which makes sense, given that Mozilla's Servo rendering engine also has the goal of being that kind of software.)
Web browsers are not that kind of software. The web is evolving much faster than any of the other things you mentioned. New features get proposed every year, and you just have to deal with it and implement them, even if they complicate the implementation of the browser. Even if you cut that off, you still have to deal with the horrific mess that is the cumulative total of past web-related decisions.
There's certainly a layer of a rendering engine—the part that translates a CSSOM into rendering pragmas—that changes a lot over time. But rendering the resulting pragmas itself doesn't change much, and features requiring new pragmas come about remarkably slowly.
Clearly, though, you know what a rendering engine is, so I'm not sure what your argument in the GP post was. Was it just a tangential statement (i.e. "rendering engines are well and good, but it'd be silly to write the browser itself in Rust, for [reasons]"), rather than a rebuttal...?
In the case of startups, their goal is to sell out way before the maintenance phase of the lifecycle. So, it doesn't really matter to them so much as quickly getting out working features. In other cases, esp long-lasting endeavors, then this is a good point to consider.
Or grow so quickly that replacing most the legacy code from a year or two ago is not a significant hurdle at their new size.
In this vein, I wonder if there's actually a third path that might be better than both. Using a low-level but fairly expressive and strongly typed language but very loosely, such that it allows you to iterate fact but with less performance, and you can come back later and replace chunks as needed, but with the same language. I don't have any real experience with that, and I could see it going either way for a number of reasons, but it seems like we have more languages that might fit that criteria now (or at least they are more popular now) than we have previously.
Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." They were speaking from their own experience, based on their own balancing of the trade offs as a user. Presumably a REPL doesn't rate very highly for them.
However, the reasons we don't have a REPL are mainly two: the compiler isn't architected for it and code doesn't compile fast. The solutions are:
* Re-architect the compiler to support incremental code input. This is pretty similar to what we need to support IDEs (which we're working on), so possibly this will solve the problem.
* Get a reimplementation of the backend which is a JIT interpreter instead of LLVM, which takes up most of our compiletime. Work is underway on a project called miri, though it isn't officially supported right now.
* Make the typechecking part of the compiler faster. This is underway through a project called chalk.
In other words, a REPL is not impossible, it just isn't a top priority right now. There are other lacking tools that we're working on - IDE integration and auto-formatting for example - maybe after those are done it will be the top of the docket.
It's a relatively recent addition though.
Respectfully, the community has become increasingly vocal, and it's getting hard to separate the enthusiasm from realism. It's embedded in every HN thread. That's a good problem to have, but it can be a bit repellant to people who aren't Rust converts.
Thanks for the breakdown and future roadmap. I hope the compile times can be kept to a minimum in order to avoid C++'s fate.
Define productive.
Are you measuring raw lines of code generated?
Or are we measuring amount of production-ready code?
My bet: with an experienced, diligent developer it's a wash. My gut says what you lose in a slow code-execute cycle of static, compiled languages you gain in lower defect rates from compile-time checks. Conversely, what you gain in a dynamic language, you lose in errors caught at run-time.
At that point I'd select for languages that are simpler with fewer surprising semantics (crossing Perl and Javascript off the list), with more built-in run-time and/or compiler safety (knocking things like C off the list). I generally also prefer compile-time safety over run-time safety, as I'd rather find problems on my workstation than in the field because I missed testing a codepath.
Actually, I think Perl has fairly few surprising semantics after you learn the major ones. The real problem is that the major one (or specifically the major one, context) is somewhat hidden in normal C-like usage until it jumps out at you and confuses you. Once you understand what it is, it's not all that surprising (but there are a few annoyances with it that still persist and cause problems). You can write Perl that looks almost exactly like C 95% of the time, but that 5% where it matters makes people that do this very confused. There are, of course, other parts of the language that are poorly chosen, but I maintain there are actually far less of them than many people seem to think.
As for JavaScript, I still can't get over all the different ways to check for equality and null or undefined. I understand a good portion of that is because I never have to use JS enough to become truly proficient, and some if it is just poor design.
That definition excludes any bare-metal language, and use cases where you want to take advantage of cheap low-level memory protection features such as No-Execute bits. For me, a more interesting benchmark would be how well Rust fares in implementing the runtime of a higher-level language.
In other words, if you can't implement a REPL, that's the definition of "less productive language." It's not about the REPL itself but the capability of implementing one.
Think about it like this: On your list of languages, which of them would you say is most productive? It depends on the context, certainly: libraries, familiarity, etc. But let's assume the languages had identical ecosystems, and that you were competent in all of them. Which of them would take the smallest amount of time to write your feature?
That'd probably be Python, Haskell, or even Perl. It seems very difficult to argue that Rust would top them. And the reasons why this is might be true are worth examining.
Here's another aspect. Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? How about 20? 2?
It becomes very difficult to argue that your programming language is the lingua franca of the future. (And that's probably true for every language, not just Rust.)