Ironically the "simple" JS program has a bug in it. The documentation for fs.watch is very explicit that the filename in the callback can be null and that you need to check for that. In Rust that fact would be encoded in the type system and the programmer would be forced to handle it, but in JS it's easier to just write bad code.
Typescript would require you to check for null before use, which I think makes this a good example of how TS is oftentimes a fairly gentle step up from JS. Or, at least, closer to the correctness of Rust without all the heavy stuff.
JS will immediately error on the lack of parens, but the `in` vs `of` iterates over indexes, not values, and those indexes are unfortunately converted to strings (since `for-in` is object field-name iteration). So even TypeScript would not have caught it when the (stringified) index is used as the first argument of `fs.watch()`.
True, but also the loop syntax is simply incorrect, which would have been caught by running it; so probably a better interpretation is simply that the author didn't spend much time thinking about that JavaScript code because it didn't matter for their point.
Yes. It's coming from the Rust code (where the relevant property is named 'kind') because the author didn't actually run their JS snippet. They've (silently) fixed a number of issues people have pointed out (including the one I pointed out) but they still haven't noticed that one.
println can only print things that implement the traits Display or Debug. As a result, Paths cannot be printed directly.
Not all OSes store paths compatible with UTF-8. In Rust, all strings are UTF-8 encoded. Thus printing a Path is a lossy operation (i.e. cannot safely be round-tripped). Path exposes a `display` method returning a type that implements Display. This is a fact Rust is encoding in its type system, whereas in JavaScript (and TypeScript), it's not really possible to state "strings internally are UTF-16 and you may need to invoke TextEncoder / TextDecoder to safely deal with paths that are not Unicode". If you fetch from a server sending Shift_JIS text and invoke `response.text()`, you get an empty string at runtime (in my experience). If you aren't experienced in dealing with text encoding issues, I can see this becoming a lengthy debugging session.
As others have noted, the JavaScript program has a bug not present in the Rust program, and a syntax error (should probably use for..of, not for..in). The example definitely uses more concepts than "first-class functions". You still have to understand iterators, just like in Rust, and it uses CommonJS instead of ES Modules, but I digress. The usage of async/await and Promises is another concept to teach, and the usage of top-level await is specifically something that wasn't supported in some runtimes (e.g. Node) until recently. It still isn't supported in the latest version of some mainstream JS engines (e.g. Hermes, which is used in React Native)
To your above point about paths, it’s things like this that keep me coming back to Rust. This was just one example, but other languages are absolutely littered with pitfalls and gotchas that—individually—aren’t all that likely to happen.
But all of them? Over a given program’s lifetime? In aggregate these end up being responsible for an absolutely wild number of random bugs that crop up in your exception logs that need to get tracked down. And it never ends. There are an infinite number of edge cases you’ve never thought about that aren’t fully handled and that some of which are constantly being tripped.
This just… doesn’t happen in Rust. The type system catches (and/or completely rules out) a ridiculous number of these situations. I have repeatedly written finished software in Rust, where once it was released there was only an occasional need to add features but the typical bug-squashing treadmill just doesn’t exist.
That’s not to say there are never bugs. You can express faulty logic in any language. But the number of stupid impedance matches that are categorically ruled out makes the experience of operating and maintaining Rust program once written a widely different experience than I’ve had with any other language.
I spent months working out all the kinks of a C++ codebase to make up for decades of assumptions about paths and strings and locales that failed to stand up to reality.
The 'difficulty' of Rust would have been preferable, in hindsight.
I find that understanding thenables/Promises and async-await in JS/TS is emphatically not something a lot of devs really understand. It really shows when you see something like...
var fn = async (param) => new Promise((res, rej) => {
...
fooLibraryCall(param).then(res).catch(rej);
});
I've literally seen similar to this... where devs see wrappers for the callback syntax, then apply the same to thenables and use manual Promises inside an async labelled function. It makes my mind bleed to see it, and I've seen it a few places.
Then, of course, there's dealing with module imports and async import() methods and how they operate or get transpiled or split, etc.
Sometimes you still need to work with promises even inside an async context. Imagine an async function which needs to `await Promise.all([...])`. In this case, `then()` can be a useful tool to make new promises from an async call.
The Bjarne quote is basically sales pitch for a recurring rationale to make C++ worse and worse. It was, I suppose, not unreasonable to assume Bjarne was sincere the first time, but that was a long time ago. Here's how it goes:
1. “Within C++, there is a much smaller and cleaner language struggling to get out”
2. However just subsetting the language to get at the smaller one would not be a cleaner language. Instead we must first make a superset language, adding features, then we can subset this new language to reach our smaller but cleaner C++
3. Step one, superset will land in C++ N+1. Planning of that "subset of a superset" will need to wait until we've completed that work.
4. C++ N+1 is an even clunkier behemoth. Rinse and repeat.
I don't understand why people who've seen this happen more than once would stick around. You're not going to get the "smaller and cleaner" language after step two, there is no step two, it's just going to be step one again and then step one again, and then step one again, forever.
reminds me of the classic https://xkcd.com/927/ not exactly identical to Bjarne's quote but similar.
I'm quite familiar with C++ as well and this just jives so much, each standard is just almost exponentially more complicated than the last, and while there are good changes they don't necessarily fit well with the prior version and its just a mess, I still maintain two OSS libs but I don't use the language anymore.. so its a question of how long I put up with it at this point.
Rust is such a breathe of fresh air coming from c++11/14/17/20 but its still a behemoth if you don't know the entire thing, I think this article is pretty spot on with that.
Anyone else get completely side tracked as soon as you saw the shebang (self-executing rust scripts)? MY mind kind of exploded in a similar fashion to when I discovered Go could do the same. It's definitely a nifty feature and can see it getting a lot of basic usage. I've seen a couple projects that do similar with rust to control build and testing pipelines, this could be a good alternative in those cases.
That said, I mostly just use Deno + TS for my shell script needs beyond simple bash. Mostly in that JS is hands down the language I know the best (28 years), close would be C# (24 years) for me. I was also an early adopter of Node. I also think that dealing with shared/centralized packages is an easier option for Deno than Node, Python or other languages/environments. The cargo front-matter here seems to work similarly.
As the person designing and implementing cargo script integration into cargo (there have been many third-party implementations in the past), I was both glad to see it in the wild and surprised and glad to see it called out like this!
Yes, there has been a long road to this in defining what this should look like, how it should interact with the language, what is the right scope for the initial release, and so on.
At this point, I'm doing what I hope is the wrap up work, including updating the style guide and the Rust reference. The big remaining work is in details I'm working out still for rustfmt and rust-analyzer. Other than those, I need to get to a bug fix in rustc and improve error reporting in Cargo.
For myself, I use cargo script nearly daily as I write a script whenever I'm creating a reproduction case for an Issue I'm interacting with.
Just to add, I literally meant sidetracked... started searching for the "-Zscript" feature in cargo, apparently in progress since 2023 with an open issue that's close to complete. Along with looking back into ZomboDB's repo, where I saw Rust being used for the build pipeline stuff, not that I completely understand it in context.
Not to mention how useful the cargo front-matter handling is in terms of portability for these kinds of scripts... one file to share, and no extra "install/init" step to bring in dependencies (such as with say Python or Node.js).
> That said, I mostly just use Deno + TS for my shell script needs beyond simple bash. Mostly in that JS is hands down the language I know the best (28 years), close would be C# (24 years) for me
I sympathise, but in 2025 that is a terrible reason to choose a system.
A lot has changed, mostly for the better, much better, in the last twenty years
I know it, understand it, it's easy for me to use, modern, can run without complex initialization/setup, a massive amount of module support including plugging into almost every kind of backend under the sun, and portable as a single file/script.
Those aren't good reasons to choose something?
I mean, sure, I COULD use Python or Go, or actually build small programs in a number of other languages instead of scripts altogether... But Deno+TS is actually a pretty good and capable shell scripting option. I'm not bashing on Python or Go here.. but given that I KNOW one of these options better than the others, it definitely is more than enough to tip the scales.
Unless you're making the assumption that my starting with JS so long ago means I don't understand modern/current conventions?
I saw an example about a year ago and can't find a specific article... but something along the lines of...
#!/usr/bin/env -S go run
I'm not sure if/when go ignores a shebang on the first line... otherwise, there are a bunch of articles I've seen that have a slightly differing format to do the same.. but google results feel off/old.
searched for: go shebang scripts
shebang is the term for a text/script file beginning with "#!" with the executable and parameters to run.
I know this... my point was in that Rust didn't have this feature 5-8 years ago when I first started reading/learning about it. A lot of languages haven't had an active scripting-capable usage that can do this until fairly recently. C# even has it in .Net 10, though I'm not sure about dependency handling in that case.
I like and was commenting that rust has the cargo frontmatter instead of a separate cargo file, same for deno in that it can reference the repo/url directly instead of requiring a separate modules file/folder (like node package.json/node_modules) or even with python. You can reference the modules you need directly.
Most languages currently do not support this in a way that lets you specify dependencies from a package manager. And some don't support it at all; most C and C++ toolchains, for example, don't have a way to compile and run a single source file in a single command.
So what exactly is the "much smaller and cleaner language struggling to get out" of Rust? If I'm understanding the post right, that language still has references, lifetimes, traits, enums, etc., because all of those features cohere; you can't remove just one and expect the rest of the language to still work. Once you grant all those features, your language isn't much smaller or cleaner than Rust; your language pretty much is Rust.
The last section gives two different hints as to what this "smaller and cleaner" language might be, but neither of them fully makes sense to me.
First, withoutboats's "Notes on a smaller Rust". That post and especially its sequel are great and I like them a lot, but the title is fairly misleading as to what they're getting at. The language that boats sketches out in those posts has significantly different design goals from Rust; in particular, it abandons the requirement of low-level programmer control over runtime behavior, and so is unsuitable for many use cases that Rust is used for. The idea, rather, is to explore what lessons Rust can offer for the design of a language with more "mainstream" requirements (i.e., one that can afford things like a tracing garbage collector, and wants to avoid Rust's downsides compared to other popular languages, like slow compile times and heavy syntactic salt). That language is not "struggling to get out" of Rust; Rust doesn't want to be it.
Second, "In a manner of speaking, that smaller Rust is the language I fell in love with when I first learned it in 2018. Rust is a lot bigger today, in many ways, and the smaller Rust is just a nostalgic rose-tinted memory." I've explained above why I don't think boats's proposed "smaller Rust" is anything like the real Rust was at any point in its history (at least after the very early days, once the designers figured out that they were targeting C++'s niche). In most fundamental respects, Rust hasn't changed that much since 2018, and a lot of the changes (like the new editions) are about making it more syntactically flexible and increasing the fraction of sensical programs that compile. That said, there are two big exceptions: async and const, which were much more minimal in 2018 and have since expanded to big complex meta-features with many interlocking parts that weren't part of the language's original core. If the claim is specifically that Rust was smaller and cleaner before async and const, then by all means, say that! But the post doesn't, leaving us to try to figure out what was meant.
> So what exactly is the "much smaller and cleaner language struggling to get out" of Rust? If I'm understanding the post right, that language still has references, lifetimes, traits, enums, etc., because all of those features cohere; you can't remove just one and expect the rest of the language to still work. Once you grant all those features, your language isn't much smaller or cleaner than Rust; your language pretty much is Rust.
I think there's an argument to be made that you could in fact make a simpler language than Rust while keeping the core concept. This variant of the language would remove:
- the Copy trait
- reborrowing
- deref coercion
- automagic insertion of `into_iter` in loops
- automatic call to drop at the end of scope (instead you'd have to call it by yourself or get an compiler error)
- trait bounds having an automatic `:Sized` bound by default.
- lifetime elision
- no “match ergonomics”
- and likely a few other pieces of “magic” that can be hard for beginner to grasp, but that's what I had at the top of my head.
This language would be much simpler, by having fewer concepts and a lot less “magic”, but it would also be much more cumbersome to use in a day to day basis, as all of the above are clever workaround designed to make common tasks as straightforward as possible, and I don't think anyone would prefer to use it than using Rust itself. It may be useful as an instructional tool when introducing Rust to students though.
I'm actually unconvinced you could do without `Copy`. It's both in the core of the language and essentially required for stuff like shared references to work correctly. Copying could be replaced by a keyword instead of happening implicitly, but that's different from removing the concept entirely from Rust.
The rest, sure, you could do without (reborrowing can't be emulated but I don't think it's strictly necessary to write real code). I'd add catchable exceptions and the use of traits instead of explicit modules as things that I think tremendously complicate the language semantics and are almost certainly not strictly necessary to achieve Rust's language goals.
Do those features actually cause difficulty for anyone other than compiler engineers, compared to not having them? I haven't personally seen, e.g., newbies stumbling over them; they're actually designed remarkably well to fade into the background and Just Work (i.e., you don't notice they're there, but you definitely would notice if they went away). Yes, there's something to be said for minimalism in language design, but Rust without those features still isn't very minimalistic, so dropping them would seem to bring about most of the costs of minimalism without the benefits.
This doesn't strike me as much simpler than Rust; it has most of the features listed above. I know a lot of people don't like RAII (which Rust has and Austral doesn't) because they want every function call to be visible at the call site, but replacing that with linear types, whatever their other virtues, does not make the language easier to learn; implicit destructor calls aren't hard to understand as a concept, once you've got your head around the notion of a value with a specifically bounded lifetime, whereas fighting the linearity checker seems likely to be an even greater speed bump for new users than fighting the borrow checker (which Austral still has).
you were reading very closely, well done. yes, that is my claim, Rust was smaller and cleaner before async and const. I was so indirect about it because many of my best friends work on those features and I wasn’t sure how to word it. fortunately Matklad has worded it very well on the other site: 2015 rust was a more complete language that cohered better, but the vision of Rust is not to cohere perfectly, it’s to be an industrial language that is useful even if it’s not beautiful.
Yeah, in that case I think the link to boats's work obscures the point a bit.
I take what might be a slightly different read of matklad's point; I don't think Rust has much compromised its vision in terms of which broad features to support, but it has on a couple occasions chosen to ship something that wasn't perfect because being useful requires taking only a bounded amount of time to iterate on design.
So Rust 1.0 shipped without async, even though it was known to be needed for some of Rust's core use cases, because it was too far from being ready and it wouldn't do to wait forever. Once that decision was made, it had implications for how async could work; in particular, really doing it right requires linear types, but this wasn't appreciated when Rust 1.0 shipped and it's not a backwards-compatible change, so by 2018 it was off the table. The choice was, do async in a way that works with the existing design decisions, at the cost of some elegance, or don't do it at all. The former choice is not just more "industrial", I would argue that it coheres better, because waiting for multiple events at the same time is a core feature that a language for foundational software has to have, and the combinator-based approach that people were using in 2018 cohered poorly with the rest of the language (e.g., requiring unnecessary heap allocations). So this wasn't really a compromise to coherence.
(This also happened on a lesser scale when async/await first shipped—e.g., specific "async" syntax instead of a more general coroutine feature—because of eagerness to ship something that year. boats has claimed that this was a matter of existential survival for the language; I'm not sure I agree. But while async/await is a bit less conceptually pure than fully general coroutines, I don't believe that any of today's common complaints about async are downstream of the decision at that time to try to ship something quickly; there don't seem to have been a lot of obvious mistakes from then.)
(My understanding is that const has a similar story but I'm less familiar with the design space there, because people haven't exhaustively chronicled its history like they've done with async, perhaps because it's not as heatedly controversial.)
I know I'm biased, but Rust is the closest thing we have to a perfect programming language. Is the borrow checker a pain in the ass? Yeah. But is it necessary? Absolutely. Imagine writing the same buggy program in C, deploying it, and then it blows up at runtime—you still have to fix it, right? A bug is a bug, and it needs fixing. The difference is Rust forces you to deal with it before you even get a binary, while with C you might get a 3 a.m. wake-up call trying to figure out what went wrong. So it’s not that Rust is harder, it’s just different. It takes a paradigm shift in how we think about writing safe and secure code. Change is uncomfortable in general for humans and that paradigm shift is precisely why most (I hope not) people feel this way about Rust.
* I think Rust gives the compiler too much freedom to choose whether or not to apply Deref (and in what order). The whole .into() and From trait allows the compiler to perform arbitrary type conversions to make the code work (the standard library is full of similar "convenience" traits and functions). All of these tend to hide the types of a objects, making it hard to map a function call to an implementation (though a good IDE can help with that).
* I think implicit return values is a misfeature as it makes flow control implicit, hiding it from programmers reviewing the code. I'm also not fond of the question mark operator, though syntax highlighting helps a lot with that.
* Rust modules are generally too small so that you need hundreds of dependencies to do anything useful. Each of which you need to separately vendor and periodically update if you need deterministic builds.
* Async Rust is a hot mess right now
I didn't say perfect, I said closest to perfect. Regarding the implicit return types, it's all a matter of taste. I think they're very clean, but Rust is not forcing you to be implicit—you can be explicit if you like. e.g., if a function's return type is String, then whether you write the implicit "Hello".into() or the explicit "Hello".to_string() or String::from("Hello") is entirely up to you, and Rust will not complain.
> Is the borrow checker a pain in the ass? Yeah. But is it necessary?
You've missed the primary point of the post entirely. Borrow checker per se is not the problem; it's the sheer amount of everything. There's multiple ideas of perfection. Those of us to have very much enjoyed ostensibly imperfect Rust of 2018 find this particular, current flavour unappealing. It may as well be capable tool in deft hand, however, as-is the case with everything in life, you cannot help but ask yourself THE question; is it worth my effort? For me personally, if I were looking for better C/C++ in 2025, I would choose Zig before Rust any day of the week (one exception being Postgres stuff, pgrx ecosystem that is really special!)
But then again, anything beats writing C for a living.
I often encounter people that want to learn a programming language and ask if they should pick Rust as their first language. My answer is universally: NO.
Learning a first programming language is hard. And Rust will only make it harder since all you're going to do is debug compiler errors all day and never even see your program actually run until it's "perfect". This will be incredibly frustrating and you'll give up.
I always tell people to start with Python, JavaScript, or Lua. You can make something fun and interesting for yourself, like a game, and get immediate feedback and you can iterate quickly.
Not my experience. We have an ML engineer at work that has only worked with python. He wanted to contribute to our rust codebase so I spent about an hour going over the basics of rust with him, and answered questions as they came up, and he was able to get up and running very quickly. He quickly became quite productive in our rust codebase.
And theoretically, I'm not sure it's that very fun to run your game, have it crash because you passed a string to a function that expected an integer, stare at a backtrace, see where that variable came from, go up the call stack a few levels, and then realize "oh, i forgot to parse that string after the user typed it in". I'd rather get a compile error that underlines the problematic code and says "this is a string, but the function expected an integer". It may be debugging compiler errors all day, but the alternative is debugging runtime errors all week.
I'm not convinced. I want to see Rust as First Language attempted by somebody good. The staff who taught me the Standard ML of New Jersey are retired, and the current programme head is a friend who disagrees with me strongly about how this entire discipline should be approached, but in principle I feel it ought to be interesting & might be extremely productive for the cohort.
I think worst case it's a "sink or swim" course where a large fraction of the cohort wash out and that's bad for numbers (which will annoy bean counter but for a prestige university might actually be OK medium term) and best case the wash out rates are no different but the good students are receiving a lot more value than for today's First Language which is (at the university I'm thinking of) Python.
I think the move assignment semantic and the use of "const" to mean constant are examples of things where Rust is significantly penalized by having older languages teach their insane choices as just "How it is" so that then later a Rust course needs to have students un-learn this stuff when it would be easier to begin there.
It has been attempted! I've taught if to over 400 beginners now and cannot overstate how it's not just possible but actually works pretty damn well. And students instantly have a background from which they can learn other languages too.
I'm the author of the quote at the top of this blog post. I've at this point taught rust as a first language to over 400 people and am very amused by the claims in this thread and it's comments. After a few years of doing this I'm not just convinced it's possible, but have seen a lot of evidence of it working pretty well.
Rust wouldn't be a bad language if humans were able to take it in all at once. The problem is, nobody learns like that and Rust is very hard to iterate on if you don't know a lot of the key concepts.
The problem with this is you'll necessarily have to unlearn something or be frustrated when you achieve some level of proficiency in other languages since it still requires all those concepts which don't exist anywhere else.
There is an easy subset of Rust, namely the "pure functional" subset that doesn't use reference types at all and just passes everything by value. The use of & ("shared") references is only marginally harder. All of these features can be introduced step-by-step, together with basic notions that are not exclusive to any programming language. I'm aware that this is not how Rust is generally taught, but it's worthwhile to attempt such an approach.
I would suggest Python or Lua before JS if you want to learn formally, such as following a book/series/class. JS (and TS) just have so much flexibility and many functionalities have been enhanced over the years that depend on the runtime context and build tooling in some cases.
Don't get me wrong, I love JS/TS since before the "Good Parts" book ever came out. The only advantage it has as a first language is you can start tinkering directly in the browser... Which is something I use to this day... the debug console in the browser, I can exercise a generated API client before the UI features are flushed out.
If you want to learn with the intent of "I want to build $THING." then JS/TS is probably a great language to start with... you will probably want to read something like a for dummies book to start, then bootstrap with a coding ai... and tinker until it works. Note: don't do this for anything security critical when starting out.
In general I recommend people stay away from static typing for a first language. I'm a static typing booster, but for beginners it is unnecessarily confusing.
Compiler errors are by nature often counterfactual: "compiler couldn't prove that this wasn't none" or "once you pass through this generic method it's no longer known that your list of Animal only contains members of Dog" is usually more confusing and less tractable than a concrete test case that craps out your program. Then you can start poking away with prints at the stacktrace.
If you step through every single line of your execution carefully and inspect all the data, you're virtually certain to unstick yourself. I can't say the same if you get some gobbledygook from the compiler.
I really don’t think so, but it probably depends on which languages you’ve used in your life.
I’ve spent most of my professional time in C, Ruby, and a decent amount of time dabbling around in functional languages. All of the core bits of Rust from this post more or less clicked immediately for me. The other features are there, but they’re typically not something you need to internalize to comprehend Rust as a whole.
The biggest hurdle—as for most people—was learning what the borrow checker is really trying to teach you about the structure of your programs and internalizing those lessons. But having some experience with RAII and good practices around manual pointer ownership in C helped pave a pathway toward understanding those concepts.
Nah not really. If you are in C/C++ land you know exactly what problem Rust solves. If you only even known GC languages then yeah it will be a up battle hill.
The creator has said it's not. It's compiler is in rust though. But Gleam is an entirety different language in terms of paradigms and target runtimes. It can't really replace rust
Wings3D is a 3D modeller written in Erlang so I would assume you could use Gleam for that as well given that it's the same runtime. Although I think it's probably not the best tool for the job.
Readit News
https://nodejs.org/api/fs.html#filename-argument
`for path in paths`
should be
`for (const path of paths)`
JS will immediately error on the lack of parens, but the `in` vs `of` iterates over indexes, not values, and those indexes are unfortunately converted to strings (since `for-in` is object field-name iteration). So even TypeScript would not have caught it when the (stringified) index is used as the first argument of `fs.watch()`.
Which is mostly a lie, since at least half the concepts they gripe about in rust are in the js snippet.
> console.log(`${kind} ${filename}`)
It should be `eventType` (string).
As others have noted, the JavaScript program has a bug not present in the Rust program, and a syntax error (should probably use for..of, not for..in). The example definitely uses more concepts than "first-class functions". You still have to understand iterators, just like in Rust, and it uses CommonJS instead of ES Modules, but I digress. The usage of async/await and Promises is another concept to teach, and the usage of top-level await is specifically something that wasn't supported in some runtimes (e.g. Node) until recently. It still isn't supported in the latest version of some mainstream JS engines (e.g. Hermes, which is used in React Native)
But all of them? Over a given program’s lifetime? In aggregate these end up being responsible for an absolutely wild number of random bugs that crop up in your exception logs that need to get tracked down. And it never ends. There are an infinite number of edge cases you’ve never thought about that aren’t fully handled and that some of which are constantly being tripped.
This just… doesn’t happen in Rust. The type system catches (and/or completely rules out) a ridiculous number of these situations. I have repeatedly written finished software in Rust, where once it was released there was only an occasional need to add features but the typical bug-squashing treadmill just doesn’t exist.
That’s not to say there are never bugs. You can express faulty logic in any language. But the number of stupid impedance matches that are categorically ruled out makes the experience of operating and maintaining Rust program once written a widely different experience than I’ve had with any other language.
The 'difficulty' of Rust would have been preferable, in hindsight.
Then, of course, there's dealing with module imports and async import() methods and how they operate or get transpiled or split, etc.
Deleted Comment
1. “Within C++, there is a much smaller and cleaner language struggling to get out”
2. However just subsetting the language to get at the smaller one would not be a cleaner language. Instead we must first make a superset language, adding features, then we can subset this new language to reach our smaller but cleaner C++
3. Step one, superset will land in C++ N+1. Planning of that "subset of a superset" will need to wait until we've completed that work.
4. C++ N+1 is an even clunkier behemoth. Rinse and repeat.
I don't understand why people who've seen this happen more than once would stick around. You're not going to get the "smaller and cleaner" language after step two, there is no step two, it's just going to be step one again and then step one again, and then step one again, forever.
I'm quite familiar with C++ as well and this just jives so much, each standard is just almost exponentially more complicated than the last, and while there are good changes they don't necessarily fit well with the prior version and its just a mess, I still maintain two OSS libs but I don't use the language anymore.. so its a question of how long I put up with it at this point.
Rust is such a breathe of fresh air coming from c++11/14/17/20 but its still a behemoth if you don't know the entire thing, I think this article is pretty spot on with that.
That said, I mostly just use Deno + TS for my shell script needs beyond simple bash. Mostly in that JS is hands down the language I know the best (28 years), close would be C# (24 years) for me. I was also an early adopter of Node. I also think that dealing with shared/centralized packages is an easier option for Deno than Node, Python or other languages/environments. The cargo front-matter here seems to work similarly.
Docs are at https://doc.rust-lang.org/nightly/cargo/reference/unstable.h...
Yes, there has been a long road to this in defining what this should look like, how it should interact with the language, what is the right scope for the initial release, and so on.
At this point, I'm doing what I hope is the wrap up work, including updating the style guide and the Rust reference. The big remaining work is in details I'm working out still for rustfmt and rust-analyzer. Other than those, I need to get to a bug fix in rustc and improve error reporting in Cargo.
For myself, I use cargo script nearly daily as I write a script whenever I'm creating a reproduction case for an Issue I'm interacting with.
Not to mention how useful the cargo front-matter handling is in terms of portability for these kinds of scripts... one file to share, and no extra "install/init" step to bring in dependencies (such as with say Python or Node.js).
I sympathise, but in 2025 that is a terrible reason to choose a system.
A lot has changed, mostly for the better, much better, in the last twenty years
Those aren't good reasons to choose something?
I mean, sure, I COULD use Python or Go, or actually build small programs in a number of other languages instead of scripts altogether... But Deno+TS is actually a pretty good and capable shell scripting option. I'm not bashing on Python or Go here.. but given that I KNOW one of these options better than the others, it definitely is more than enough to tip the scales.
Unless you're making the assumption that my starting with JS so long ago means I don't understand modern/current conventions?
Can you explain more? Is it this - https://stackoverflow.com/questions/7707178/whats-the-approp... ?
searched for: go shebang scripts
shebang is the term for a text/script file beginning with "#!" with the executable and parameters to run.
Any file starting #!/some/path just means for the shell to invoke that command and pass the contents of the file on stdin.
I like and was commenting that rust has the cargo frontmatter instead of a separate cargo file, same for deno in that it can reference the repo/url directly instead of requiring a separate modules file/folder (like node package.json/node_modules) or even with python. You can reference the modules you need directly.
The last section gives two different hints as to what this "smaller and cleaner" language might be, but neither of them fully makes sense to me.
First, withoutboats's "Notes on a smaller Rust". That post and especially its sequel are great and I like them a lot, but the title is fairly misleading as to what they're getting at. The language that boats sketches out in those posts has significantly different design goals from Rust; in particular, it abandons the requirement of low-level programmer control over runtime behavior, and so is unsuitable for many use cases that Rust is used for. The idea, rather, is to explore what lessons Rust can offer for the design of a language with more "mainstream" requirements (i.e., one that can afford things like a tracing garbage collector, and wants to avoid Rust's downsides compared to other popular languages, like slow compile times and heavy syntactic salt). That language is not "struggling to get out" of Rust; Rust doesn't want to be it.
Second, "In a manner of speaking, that smaller Rust is the language I fell in love with when I first learned it in 2018. Rust is a lot bigger today, in many ways, and the smaller Rust is just a nostalgic rose-tinted memory." I've explained above why I don't think boats's proposed "smaller Rust" is anything like the real Rust was at any point in its history (at least after the very early days, once the designers figured out that they were targeting C++'s niche). In most fundamental respects, Rust hasn't changed that much since 2018, and a lot of the changes (like the new editions) are about making it more syntactically flexible and increasing the fraction of sensical programs that compile. That said, there are two big exceptions: async and const, which were much more minimal in 2018 and have since expanded to big complex meta-features with many interlocking parts that weren't part of the language's original core. If the claim is specifically that Rust was smaller and cleaner before async and const, then by all means, say that! But the post doesn't, leaving us to try to figure out what was meant.
I think there's an argument to be made that you could in fact make a simpler language than Rust while keeping the core concept. This variant of the language would remove:
- the Copy trait
- reborrowing
- deref coercion
- automagic insertion of `into_iter` in loops
- automatic call to drop at the end of scope (instead you'd have to call it by yourself or get an compiler error)
- trait bounds having an automatic `:Sized` bound by default.
- lifetime elision
- no “match ergonomics”
- and likely a few other pieces of “magic” that can be hard for beginner to grasp, but that's what I had at the top of my head.
This language would be much simpler, by having fewer concepts and a lot less “magic”, but it would also be much more cumbersome to use in a day to day basis, as all of the above are clever workaround designed to make common tasks as straightforward as possible, and I don't think anyone would prefer to use it than using Rust itself. It may be useful as an instructional tool when introducing Rust to students though.
The rest, sure, you could do without (reborrowing can't be emulated but I don't think it's strictly necessary to write real code). I'd add catchable exceptions and the use of traits instead of explicit modules as things that I think tremendously complicate the language semantics and are almost certainly not strictly necessary to achieve Rust's language goals.
Austral? https://austral-lang.org/features
https://lobste.rs/c/b8kevh
I take what might be a slightly different read of matklad's point; I don't think Rust has much compromised its vision in terms of which broad features to support, but it has on a couple occasions chosen to ship something that wasn't perfect because being useful requires taking only a bounded amount of time to iterate on design.
So Rust 1.0 shipped without async, even though it was known to be needed for some of Rust's core use cases, because it was too far from being ready and it wouldn't do to wait forever. Once that decision was made, it had implications for how async could work; in particular, really doing it right requires linear types, but this wasn't appreciated when Rust 1.0 shipped and it's not a backwards-compatible change, so by 2018 it was off the table. The choice was, do async in a way that works with the existing design decisions, at the cost of some elegance, or don't do it at all. The former choice is not just more "industrial", I would argue that it coheres better, because waiting for multiple events at the same time is a core feature that a language for foundational software has to have, and the combinator-based approach that people were using in 2018 cohered poorly with the rest of the language (e.g., requiring unnecessary heap allocations). So this wasn't really a compromise to coherence.
(This also happened on a lesser scale when async/await first shipped—e.g., specific "async" syntax instead of a more general coroutine feature—because of eagerness to ship something that year. boats has claimed that this was a matter of existential survival for the language; I'm not sure I agree. But while async/await is a bit less conceptually pure than fully general coroutines, I don't believe that any of today's common complaints about async are downstream of the decision at that time to try to ship something quickly; there don't seem to have been a lot of obvious mistakes from then.)
(My understanding is that const has a similar story but I'm less familiar with the design space there, because people haven't exhaustively chronicled its history like they've done with async, perhaps because it's not as heatedly controversial.)
* I think Rust gives the compiler too much freedom to choose whether or not to apply Deref (and in what order). The whole .into() and From trait allows the compiler to perform arbitrary type conversions to make the code work (the standard library is full of similar "convenience" traits and functions). All of these tend to hide the types of a objects, making it hard to map a function call to an implementation (though a good IDE can help with that). * I think implicit return values is a misfeature as it makes flow control implicit, hiding it from programmers reviewing the code. I'm also not fond of the question mark operator, though syntax highlighting helps a lot with that. * Rust modules are generally too small so that you need hundreds of dependencies to do anything useful. Each of which you need to separately vendor and periodically update if you need deterministic builds. * Async Rust is a hot mess right now
You've missed the primary point of the post entirely. Borrow checker per se is not the problem; it's the sheer amount of everything. There's multiple ideas of perfection. Those of us to have very much enjoyed ostensibly imperfect Rust of 2018 find this particular, current flavour unappealing. It may as well be capable tool in deft hand, however, as-is the case with everything in life, you cannot help but ask yourself THE question; is it worth my effort? For me personally, if I were looking for better C/C++ in 2025, I would choose Zig before Rust any day of the week (one exception being Postgres stuff, pgrx ecosystem that is really special!)
But then again, anything beats writing C for a living.
I love that.
My happiest professional programming has been C
I guess diversity of taste is a wonderful thing?
I believe everything in this post (except `cargo -Zscript`) was in the Rust of 2018.
Learning a first programming language is hard. And Rust will only make it harder since all you're going to do is debug compiler errors all day and never even see your program actually run until it's "perfect". This will be incredibly frustrating and you'll give up.
I always tell people to start with Python, JavaScript, or Lua. You can make something fun and interesting for yourself, like a game, and get immediate feedback and you can iterate quickly.
And theoretically, I'm not sure it's that very fun to run your game, have it crash because you passed a string to a function that expected an integer, stare at a backtrace, see where that variable came from, go up the call stack a few levels, and then realize "oh, i forgot to parse that string after the user typed it in". I'd rather get a compile error that underlines the problematic code and says "this is a string, but the function expected an integer". It may be debugging compiler errors all day, but the alternative is debugging runtime errors all week.
Deleted Comment
I think worst case it's a "sink or swim" course where a large fraction of the cohort wash out and that's bad for numbers (which will annoy bean counter but for a prestige university might actually be OK medium term) and best case the wash out rates are no different but the good students are receiving a lot more value than for today's First Language which is (at the university I'm thinking of) Python.
I think the move assignment semantic and the use of "const" to mean constant are examples of things where Rust is significantly penalized by having older languages teach their insane choices as just "How it is" so that then later a Rust course needs to have students un-learn this stuff when it would be easier to begin there.
Rust wouldn't be a bad language if humans were able to take it in all at once. The problem is, nobody learns like that and Rust is very hard to iterate on if you don't know a lot of the key concepts.
The problem with this is you'll necessarily have to unlearn something or be frustrated when you achieve some level of proficiency in other languages since it still requires all those concepts which don't exist anywhere else.
Don't get me wrong, I love JS/TS since before the "Good Parts" book ever came out. The only advantage it has as a first language is you can start tinkering directly in the browser... Which is something I use to this day... the debug console in the browser, I can exercise a generated API client before the UI features are flushed out.
If you want to learn with the intent of "I want to build $THING." then JS/TS is probably a great language to start with... you will probably want to read something like a for dummies book to start, then bootstrap with a coding ai... and tinker until it works. Note: don't do this for anything security critical when starting out.
Compiler errors are by nature often counterfactual: "compiler couldn't prove that this wasn't none" or "once you pass through this generic method it's no longer known that your list of Animal only contains members of Dog" is usually more confusing and less tractable than a concrete test case that craps out your program. Then you can start poking away with prints at the stacktrace.
If you step through every single line of your execution carefully and inspect all the data, you're virtually certain to unstick yourself. I can't say the same if you get some gobbledygook from the compiler.
I’ve spent most of my professional time in C, Ruby, and a decent amount of time dabbling around in functional languages. All of the core bits of Rust from this post more or less clicked immediately for me. The other features are there, but they’re typically not something you need to internalize to comprehend Rust as a whole.
The biggest hurdle—as for most people—was learning what the borrow checker is really trying to teach you about the structure of your programs and internalizing those lessons. But having some experience with RAII and good practices around manual pointer ownership in C helped pave a pathway toward understanding those concepts.
It's clearly very heavily inspired by Rust.
The creator has said it's not. It's compiler is in rust though. But Gleam is an entirety different language in terms of paradigms and target runtimes. It can't really replace rust
Well that seems highly unlikely given the huge number of similarities.
>Black lives matter. Trans rights are human rights. No nazi bullsh*t.
No thanks. This is DOA.