> I don’t support pushing terminals to the extreme…
Reminds me of what Warp has become these days
The entire rust vs c++\c vs zig vs odin etc is so stupid. Like it is the same culture that has always been there in elitist systems language people. Meanwhile the vast majority of programmers are happily clacking away in python or js or elm or lua or whatever is getting the job done.
Go and Python are my current preference, and C being an old soul mate.
"My thoughts on the Bun Rust rewrite" by Zig's author Andrew Kelley
There aren't more forks because once you fork something you take on the burden of synchronization, or you forfeit the benefit of future upstream work. To focus on Ghostty, Mitchell has taken on the effort of maintaining cross-platform support. If I want one specific feature (or even a bunch of features) and create a custom fork, but then GTK changes, now I have to support that change myself (assuming it is relevant to me or my community of users), or figure out a way to integrate Mitchell's changes into my fork, or I risk losing my customizations by having to rollback to baseline if the differences between my fork and baseline are too great.
If the system is well-engineered (the work on libghostty helps here) then you can keep that common core without forking, and fork just things on the periphery of the system. But well-engineered is not common.
This is just so weird to me, because I would say the same about Zig.
I tried to get into Zig even chatted with Loris Cro when he was streaming. I was looking to explore what my Rust project could look like in Zig but there were features simply missing that I couldn't do without. The entire interaction was mostly about how bad Rust is and how I could just do something different in Zig (completely misunderstanding my ask, with little interest to explore my actual requirements).
I remember watching HN and seeing every time there was something Rust related trending, there was ALWAYS a post made shortly after trying to hype Zig and this went on for like 4 years.
I'm not a Rust contributor and I don't care for some of the challenges that come with Rust, but I love what it accomplished and I find it does it very well. Back then I found the Rust community had interest and respect for Zig, so the discourse was very much one sided.
I wonder if it's not that different people have entirely different experiences:
If you are outside the rust community, you'll mostly interact in the context of language flame wars, "why don't you just rewrite it in rust", etc. That is, you interact with the (small) part of the rust community that is most likely to want to dismiss other languages and want to brag.
I consider myself in the rust community, on reddit, the rust forum, etc, and I find it extremely well-meaning, inclusive, supportive of beginners, thoughtful, and generally a very pleasant bunch.
> PowerShell gets a lot right with structured data.
CLI programs should operate on text. If you want to parse and format it, do so, but the default output mode should be plain text, so that I can pipe it into grep or awk without a second thought.
I am continuously irritated that the AWS CLI defaults to outputting in JSON. No one (I hope…) is using that tool in programs; that’s what boto3 and its ilk are for. But if humans are reading it, why default to something that they’re almost certainly going to be piping into jq if only for the formatting help?
That's all that needed to be said. He only makes himself and the rest of the Zig "community" look as petty as some of the worst Rust people with the surrounding remarks. Why does anyone need to care what a few randoms think of a language? Either it gets used or it doesn't.
Maybe try Odin. Based on what I have read, it’s basically C capability-wise with better ergonomics - a simple language; no objects and limited compile time shenanigans.
TL;DR: No comment.
The stupid thing is getting up in arms because someone said something you don't like.
"Even C++" makes no sense. That's exactly where you'd expect it to be mentioned because Rust is pretty much aiming to be a C++ replacement. Mentions in the context of Zig also make sense, because Zig is aiming to be a C replacement in the same way Rust is aiming for C++, and C/C++ are overlapping areas.
You don't see much mention of Rust in discussions about something like Lua, because those are very distinct.
Some other reasons you might see it mentioned fairly often: Rust solves some issues at compile time that many languages solve at runtime using GC, making lower level programming more approachable for high level programmers and broadening its target audience. It has also had extremely active evangelists all over the place for a very long time, causing not mentioning it to trigger annoying derailment of discussions.
I don’t use Zig, and frequently use Rust, but I’ve never really interacted with the core development team for either. I don’t think it’s necessary to care about whatever culture is driving development once it has sufficient velocity. The Rust I use today is more than enough for my needs. Maybe if I were more involved in open source I would better understand why culture matters, but unfortunately I’m mostly a consumer of it, not a producer.
That's just engineering communities in a nutshell...
I might stay away from a particularly toxic community or one with wildly different values, but I don't really get why you wouldn't write Rust just because of how some people post about it. Odd tbh. I find the whole thing about "oh the rust zealots" hand wringing stuff so silly, really.
Then why is it weird if you're saying the same thing? Different programming languages appeal to programmers with different tastes, and so it makes sense that some programmers would be drawn to language X and dislike language Y, while others would be the opposite.
You just got a tiny taste of what Rust enthusiasts have been doing to every C++ related submission here on HN for years.
Ghostty is fine I guess, I find it to be way buggier than iterm with a fraction of the features.
Zig is fine, has some cool stuff, the community seems roughly the same as the rust, with again just way less features.
The rest of the hashi tools are fine, I don’t really use any of them anymore. Vault was a big deal at some point I guess
In hindsight (and at risk of starting a flame war), it's easier to be magnanimous when you are winning/have won.
As somebody who’s fascinated by programming languages in general, I’m quite keen on Zig. I prefer Rust, and disagree with a bunch of things Zig does, but admire the language for trying.
Mostly because in the pi.dev ecosystem there are so many similar extensions and usually everyone wants their own little special something, but then everyone could benefit from maintenance updates/bug fixes.
Funny you should say this. 4 of the last 5 companies I've worked at have quietly been using Rust in small but key parts of their systems. As far as I know, no one outside of those companies ever publicized it. They adopted it organically and kept it around because it kept working.
Everyone loves to whine about the Rust Evangelism Strike Force but the amount of "quiet Rust" out in the wild is a lot larger than most people would guess.
He didn't say that in the interview. Or, he didn't make nearly as broad a claim as you have made. He said:
>> If you want me to maintain a flag to remove it, I can ask you to maintain a fork removing it. Telling people to “fork it” often upsets them.
The context of his statement was people wanting a feature (search as one example) removed (or removable, via feature flag). In that case, the fork is about as hard to maintain as the feature flag, assuming the software is reasonably well organized.
But in general, your claim is not true, and it's not what he wrote.
> You should address the point Mitchell made
No, I have no obligation to respond to something that he didn't say.
First, to be honest about my own feelings toward Rust: as you know, Rust's traits feel like a mix of Haskell's typeclasses and OOP, and that mashup of multiple languages just didn't click with me. I'm not a fan of solving compiler puzzles either. Especially when I've used AI to generate Rust code, it produced a lot of bad code relying heavily on clone, so it's not a language I'm particularly fond of.
In that sense, I do understand part of what you're saying. I suppose this is exactly the "emotional longing that isn't being satisfied by the technical reality" you mentioned.
So then why does the community keep holding Rust up as this symbol?
That's the hard part. Rust's promise is solving undefined behavior. But UB has already been largely solved by GC languages too. So what is it about Rust that pulls people in? Is it because it replaces C and C++, the oldest legacy in programming? Or is it because it's hard for a new superstar to emerge within the legacy that C and C++ created, so people are drawn to Rust as a fresh language? I really don't know. It's a tough question.
Edit: Thought about scare quoting “taste”
In fairness, Loris Cro is “VP of Community at Zig Software Foundation” so if there’s someone to judge the community by, Loris has more weight than just about anyone (perhaps excluding Andrew Kelly).
Note I am not agreeing with your parent post, what I have seen from Loris and Andrew makes me interested in trying Zig.
> Culture wars are sadly one of the biggest inhibitors of progress
You can substitute that with Rust and it sums up my feelings. The language is great, the obsession with static typing and memory safety from its fans, as if it’s the panacea to all problems in computing, is obnoxious and smells of inexperience. It’s not a coincidence that Rust these days is baby’s first low level language, so you get a lot of strong, uninformed opinions on software design.
In the AWS case the tools talk to an API server, so sure, you can call the API server directly or use a wrapper that does, but what about all the other CLI apps that don't? The CLI program is the API.
I built a CLI program that wraps luks + btrfs, and they only offer a `--json` output option for a few commands. I have to write an ad hoc parser for each command since raw text includes arbitrary formatting and presentation lipstick that the creator came up with. And I have to do extra work to avoid breaking changes at the parser level instead of the higher data level.
If I had to pick between the two, json would at least solve the data representation part so that I can build on top of it. And it's trivial to go data (json) -> pretty print rather than pretty print -> data.
I can see it being annoying if all you care about is using CLI programs by hand, but it seems like a mild upside compared to the downsides the second you want to consume it programmatically, even if it's with a chain of awk, cut, and tr.
Which is what C++ enthusiasts have done to C enthusiasts and C enthusiasts have done to assembly enthusiasts.
Experienced Go devs that stay inside the ecosystem try to write their libraries as "pure go" libraries with zero dependencies other than the upstream core libraries (or golang.org/x if needbe), which results in a very low maintenance ecosystem. This combined with the strong toolchain makes it joyful to work with.
I still don't agree with a lot of design choices of the language, but I realize that I can be more efficient if I am setting aside my opinion.
And that's exactly the thing that somehow never happened in the Rust ecosystem. I always joke that the Rust ecosystem has more OpenGL bindings than developers, because there's just so many low quality bindings or wrappers out there that the ecosystem in result got too noisy to maintain.
I don't want to write more (verbose) code. I want to write less.
I kind of already know that my comment goes to shit in terms of downvotes, but that's what I expect while writing this. How dare I criticized Rust as a language? How dare I, a fulltime noob, do this? Rust is better, always!
...the Rust ecosystem is just so effing toxic. I am glad that I left it. I just got tired of being angry at random online things all the time. Go is my happy place where my annoyances are reduced to Cgo, maps, and the unsafe package <3
For decades, I have used a great number of video terminal emulators. I have used for long time intervals at least 8 or 9 video terminal emulators, from the original xterm until the one used immediately before ghostty, which was kitty (and including Konsole, the Gnome terminal, the XFCE terminal, WezTerm and others).
I consider Ghostty the best video terminal emulator that I have used. For now, I have not encountered any noticeable bug yet, even if I spend a lot of time using it.
Nor have I encountered any feature that I really miss (though a few things that worked in other emulators, do not work, at least not with the default configuration, e.g. setting the title of a tab window with the standard escape sequence of characters; but the ghostty titles are fine, i.e. the pwd value while in shell and the invoked command otherwise).
I do not doubt that there may exist some bugs or missing features, but it seems unlikely that they can be seen during typical workflows. I have used it only in Linux, so I do not know anything about bugs under macOS.
Hmm... I'm using ghostty (on macOS) since it was released and have yet to encounter a single bug. Iterm2 simply got too fat and slow over time, which was the point where I went terminal-shopping (first wezterm, which is also fine, now sticking with ghostty).
Rust's big tentpole is "no memory management bugs, everything must be provably safe", whereas Zig is very proud of "no memory management, you have full control but you have to exercise it". I don't feel as though these are competing for the same audience or mindshare.
I've used Zig a big (while trying to contribute to ghostty, at least), and it's an interesting language that I like the aesthetics of but I don't want to use. I use Rust for things because it's so specific about what it wants from you and won't let you go off-script, and frankly I find that very beneficial for myself as someone coming from Python, Javascript, PHP, etc. where you just let things fall out of scope and it's not your problem anymore (usually).
Linux tools that are starting to output raw JSON by default are indeed a nuisance, but how else can you achieve structured output if no standard shell supports it? It's a chicken and egg problem.
It's got a lot of the unpleasant clunkiness that something like the Bourne shell owes to decades of compatibility, but Microsoft doesn't have that excuse. Despite this, it's gratuitously incompatible with itself, I had code which worked fine, we upgraded Powershell oh, now that won't work, just fix all the scripts. Crazy. It clearly wants an NPM-style experience where you seamlessly incorporate other people's work, but then it doesn't really deliver this well and so you often end up manually copy-pasting.
If Powershell was a one man project and this was their Beta I'd say it is promising. But it's a project from the Microsoft corporation for 20 years. Do better.
Basically Unix has a long tradition of "everything is a file" and a big ecosystem of coreutils that are based around text and windows.. didn't. You can't look at /dev or /etc and learn anything about the machine. They had a few generations of APIs and wanted to give admins and power users any shell at all instead of a GUI. So the shell is centered around making those APIs accessible, rather than piping grep and sed or whatever.
me> This [API | language feature | whatever] seems harder to use than it should be.
them> No, it's actually not.
me> Here's irrefutable proof.
them> Well at least you have memory safety.
me> But...you can have memory safety without this thing being a dumpster fire. Wouldn't that be better?
them> <no concessions, Rust is perfect>
After a few conversations like that, I've literally had those same otherwise high-caliber engineers spend days wrestling with the "easy" thing we were quibbling about. I'm sure it's not intentional, but it comes across as religious gaslighting.
And maybe I just interacted with the wrong people at the wrong point in Rust's lifecycle and the community is mostly very positive. I see enough people with experiences like mine though that I'm not willing to believe it's a truly miniscule fraction of the language's discourse.
Because unix shell is irrevocably text-oriented, kludging in something like JSON is basically the best that can be done when you start to want to do structured operations on structured data. (I'm sympathetic to your point about the AWS CLI tools doing JSON by default though--that just sounds like bad design.)
Being text-oriented imposes drastic limits on composability. Because there is no structure, every element of a pipeline needs to do its own parsing of the input data. This leads to brittle pipelines where every element is tightly coupled to its input's textual representation.
As an exercise, try to write a pipeline that sorts podman images by size without removing the column headers[0]:
$ podman image ls --all
REPOSITORY TAG IMAGE ID CREATED SIZE
docker.io/prom/prometheus latest 937690d77350 2 months ago 367 MB
quay.io/keycloak/keycloak latest da9433c9fac3 2 months ago 466 MB
registry.fedoraproject.org/fedora-toolbox 43 a32da54355ca 4 months ago 2.19 GB
docker.io/powerdns/pdns-auth-49 latest 8c1385c9deed 4 months ago 208 MB
docker.io/testcontainers/ryuk 0.13.0 b75bc7ce94c3 6 months ago 7.21 MB
Contrast that with what you can do in PowerShell. You can write a couple of standalone functions[0] that are readable and composable, resulting in this pipeline:
podman image ls --all |
Replace-SpacesWithTabs |
ConvertFrom-Csv -Delimiter "`t" |
Sort-Object -Property {Convert-HumanSizeToBytes -Size $_.size} -Descending
Also, take it easy, it was merely a suggestion. The interesting part was comparing a feature/flag/branch to a fork, to me.
But all other things are not equal, are they? A vital piece of software written in C that has been battle-tested and optimized throughout its two, three, four decades or more of existence does not magically improve if it gets rewritten in Rust. Not only does that not make sense in theory, we've also seen it in reality with the issues with the coreutils rewrites.
You can make a solid argument that new software written completely from zero would be better served by being written in Rust than C. But the "just rewrite it bro" types are so incredibly obnoxious and out of step with reality.
I don't even think this is true.
You can certainly say "the security of computer systems would be a little bit better if most software was written in memory safe languages" (even more so if you went a bit further and said "with automatic memory management").
However, a lot of software exists and is useful, and the only reason it exists is because the author(s) found a way they liked to express that software.
So, for example, there are millions of companies out there, especially small ones, running all their finances on Excel. Not even accounting software. Excel. I am totally OK with this. I do not need all these companies to rewrite their Excel workflows into frontend applications backed by a relational database, even though that would be "better" in a lot of ways (more robust, easier to backup, easier to bring someone else onto...). Those little business owners understand Excel and build models and count numbers and they're happy with that. If some kind of edict compelled them to use something "proper" instead, they might not even go into business, and the world would lose whatever it is their business does.
The same thing goes for software and languages. Each language, whether it's F#, Haskell, Common Lisp, PHP, ... brings with it its own kinds of expressiveness and usefulness, and ecosystems of programmers and libraries/modules form around it. Some languages are a better "fit", sometimes for the problem domain, sometimes for the programmer's mind, sometimes for community building. It's difficult to compare any two languages because of this, and if you were to say "language X should not exist, all software written in X should've been written in language Y", you have to accept in your thought experiment that were that the case, their is likely a huge amount of software which would not exist just out of the people who made it not being happy about language Y and, if it were the only choice, would choose not to create the software they created in language X at all.
The most likely reason for why people are drawn to want to read about Rust for much the same reason. Note again that they are spending their time wanting to read about it, which is different than using it. Rust solved a real problem for a niche set of users. Now everyone who has problems with their existing technology stacks are trying to read all they can to try and convince themselves that Rust will also solve their problems. The heart lusts after Rust on the promise that it will solve all problems, but the mind knows it won't solve all problems. Attention lies at the intersection of those competing interests.
Rust is a big deal, but that isn't a big deal. MongoDB was also a big deal. Look at where it is at now. The good news for would-be language designers is that there is a strong signal in the market begging for a solution to their problems. The only question is whether you can deliver before the incumbents catch up (see: modern Postgres).
I share your complaints about the tools you came to Rust from, but the philosophy of not letting you go off script is great until it doesn't work for you. A lot of the reason some of us use the more flexible languages is because we've been in situations where a language and its ecosystem either won't let you do something outright or not without significant pain. Often when everything is on fire and your customers are cancelling contracts. You can't afford to wait for the core team or community to come in and save you in these situations.
Having access to work around your problems is also the source of a lot of the pain you're talking about, but at least you get to stay in business to solve that problem tomorrow.
To a very large degree, a lot of the Rust evangelists that I encounter in the wild are either hobbyists, academics or paid open source contributors at large companies. Most of the discussions I've seen wrt Rust at companies with actual deliverables stop at "Rust? Absolutely not.". Except for a very narrow set of systems where you want the kind of guarantees that Rust provides as a primary feature. For more general situations, the tradeoffs often aren't worth it.
It’s more important to learn how computers work and make the language just a means to understanding how they work. [...] even in this age of higher level abstractions and web development, it’s still important to understand the basics of CPU scheduling, memory, cache hierarchies, file systems, disc and file access. When you work directly above the syscall layer, whether in C, Zig or Rust, it really helps you understand what’s happening[...]
Almost all HN software related discussion will have some Rust folks saying 'yeah I have a rust project for that', or 'just write this in rust and it will be better', so annoying after seeing those each time, it's like the house-window sales guy keeps knocking my door every day and never goes away.
The elephant in the room are the trillion $ companies having a horse in this race.
But the actual UX is just convoluted and horrible. For example, the person who decided that commands without a ; at the end of the line should just vomit their outputs to the enclosing function's clearly hasn't heard of the principle of least surprise.
PS just does so many plain weird and unintuitive things, which is worsened by the fact that it looks like a boring old programming language, while clearly not being one.
I'm old-ish though and grew up apolitical, so I'm sure it's just a me problem.
Rust seems to attract a lot of horizontal programming. I have done mainly that so far and I LOVE Rust for it.
AIUI, horizontal programming is fully building out each abstraction before you start building on top of it, as opposed to vertical programming, which generally seeks to accomplish the task as directly and straightforwardly as possible, and only abstract if needed.
This leads to things like the proliferation of bindings, abstraction layers, frameworks etc. with little downstream users to show for it. And often little influence from experience using them. Sometimes very technically impressive but otherwise not always fleshed out to the point of being practically usable.
I am sure there's tons of toxicity all over the place too but I chalk it up to differing mindsets / patterns of development.
I suspect that Rust will start taking over as a dominant LLM output language.
I also suspect that in short order we'll have entirely new languages that are engineered to be ideal languages for LLMs to generate. Perhaps even safer than Rust.
The models are shockingly good at writing Rust. You don't even need to have familiarity with Rust to start using it now. You'll learn the language as you interact with the LLMs.
Then again, your very username implies an indulgence in viewing technology through the lens of fandoms which is... weird
Please provide a link to this comment.
Someone asked an honest question and got reasonable responses that were informative. At no point did anyone chide the project for not using Rust.
> Rust might be a fine language but it has the most toxic evangelist culture, bar none.
Nah, people complaining about the supposed toxic community are noisier than the supposed toxic community.
Literally all companies I've worked for a know about use Vault for storing secrets to be used during deployment.
It would be interesting to learn that this is different elsewhere.
here is an elvish shell command that converts a freetube playlist from json into a list of urls grouped by author:
for i (cat 'freetube-playlist-favorites.db' | from-json)["videos"] {
mkdir -p $i['author']
print http://youtu.be/$i['videoId'] >> $i['author']/get }
curl -s -H "Authorization: token <redacted>" "https://api.zerotier.com/api/v1/network/<redacted>/member" |
all (from-json) |
order &key={|d| put $d[name]} |
each { |device|
var t = (printf "%.0f" (/ $device[lastSeen] 1000))
if (> 20000000 (- (date '+%s') $t)) {
print (date -R --date='@'$t) $device[config][ipAssignments] $device[name] "\n" } }
Me: You're right. Java has come a long way. Let's download...
Rust: No! No no on. Not like that!
---
Memory safety is a worthwhile goal, but combining it with manual memory management is wrong for most tasks. Just use a damn GC. Rust's safety-plus-malloc niche should be much smaller than it is.
It used to be that programming languages were mostly boring and predictable, with maybe questionable semantics (const etc.), but generally that messiness meant they were good enough at getting the job done.
PL research and theory focused on mostly FP, Ocaml family and other functional languages, with things like advanced type inference system, based on postgraduate category theory. These people have fought endless and bitter mental battles with each other, a glimpse of which occasionally leaked to HN. Some paper about a noteworthy discovery in solving a problem incomprehensible to the general public. Some guy complaining about how he tried to educate average programmers about how unsound their programs were, and being taken aback at how these people didn't want to be saved from their own stupidity. Some article complaining about how if every programmer was just 15 IQ points smarter, they'd be all doing FP. But mostly this community kept to themselves.
Thanks to Rust, all these ideas have found purchase in real practical software. Now the academics get to torment themselves with the moral duty of saving the everyman from using less theoretically sound programming languages.
(Disclaimer - I don't hate Rust, I think it's great they made this breakthrough from academia to regular boring programming, but they need to respect the nuance of the world that exists outside the walls of research institutions)
$ podman image ls --all --sort=size
podman image ls --all | sed 's/\s\s\+/\t/g' | tee >(head -n 1) >(tail -n +2 | sort -hrk 5) >/dev/null
And yes, coreutils is a great example of what I mean. The GNU project was always meant to be the basis for a production grade operating system. I mean, GNU Hello is just a hello world program, and its source weighs in at 707kB zipped (or 3.6MB unzipped). The purpose is having a trivial application that can serve as reference for all the standard practices of the GNU Project. No amount of writing things in Rust can replace the engineering mentality that leads to GNU Hello existing. In comparison, as I understand it uutils was first and foremost an educational project that got coopted into being used in production. Things are very much not alike here.
If a language's mental model doesn't mesh well with yours, that's in and of itself an ever-flowing fountain of bugs, and a legitimate reason not to use it. This isn't a valid excuse to not give unfamiliar languages an earnest try, but does justify different people reaching different conclusions afterwards.
The single most important part of the mental model for programming in Excel is precisely that it takes people who tell themselves they could never be programmers, and tricks them into believing they aren't really programming, so they're "allowed" to do it by themselves. It's an incredibly empowering piece of tech. Rust and Zig and Haskell and all the other languages that excite me personally can never hold a candle to that.
> Each language, whether it's F#, Haskell, Common Lisp, PHP, ... brings with it its own kinds of expressiveness and usefulness, and ecosystems of programmers and libraries/modules form around it.
Preaching to the choir :)
"My tribe is better than your tribe"
Some people thrive inside this mentality, whole others don't go near it.
Not everyone is thinking like this but a lot of people do. So because of that it's a common heuristic to think of it as "war" because there are some people who do that gladly.
'The heart lusts after Rust on the promise that it will solve all problems, but the mind knows it won't solve all problems.' I really like that sentence.
Personally, combining your thoughts with mine, I think this is also a matter of community belonging. In other words, I don't think the issue with Rust is that it's a solved problem. Rather, I think it's a process of burying anxiety about careers and professional uncertainty into community voices, as a way to project that unease. Learning a new language and all the libraries and frameworks tied to it is very demanding, and internalizing the conventions of a language takes time. So it becomes a question like, 'What if the skills I've invested so much in are suddenly no longer relevant?'
And while Rust's approach to problem-solving is attractive, as both you and I know, no single language can solve every problem. After all, every language has its own trade-offs and subsets. As you go lower-level, cognitive load increases significantly, which is why high-level programs are often written in low-level engines and scripts in high-level languages.
Anyway, I thought this place, where the world's best programmers gather, would be different, but I'm realizing that most programmers are quite similar.
Thanks for your thoughtful input. I hope I haven't taken up too much of your time. After all, this kind of question isn't usually encouraged in communities, and it's a difficult one to answer. Everyone thinks differently. But your explanation made the most sense to me. Have a great day.
I doubt it. I think most people will become more entrenched in their favored ecosystem.
> I also suspect that in short order we'll have entirely new languages that are engineered to be ideal languages for LLMs to generate.
This is already happening. A couple months ago I came across this language that is engineered for AI and human consumption https://www.moonbitlang.com/
We get it. You like Rust. It's not a panacea.
Never used the product Vault.
If you want auto unseal with HSM and don't have to worry about the unseal key shards, then you can hook it up the HSM. Of course, HSMs are expensive and you also have to buy a Vault license.
It turns out its not 1986 anymore, and sometimes we want to output gasp images to our terminals
Decades before Rust and long before the simplified language that was C, there were safe programming languages, where all invalid operations, numeric overflows or out-of-bounds accesses generated exceptions and where use-after-free was impossible, because either garbage collectors or reference counts were used.
Rust is much safer than C compiled with its bad default compilation options, but it did not bring much in comparison with other languages.
Even in C++, with appropriate rules, restrictions and discipline you can write programs that are guaranteed to be at least as safe as any Rust program, but unfortunately very few use C++ in this way, i.e. by strictly avoiding the features that are obsolete or unsafe.
It was basically a complete derail to backdoor in a conversation about why they think everything should be in Rust.
OpenBSD still uses CVS, C and Make because that's what works for them. They will continue to keep using C, Make and CVS but that enables them to be productive with the contributors that they have. Moving things to other languages will not increase their productivity. That's the biggest thing that the largely-fanatical Rust evangelists completely fail to understand.
Unfortunately, it's not 100% correct, due to misaligned headers:
REPOSITORY TAG IMAGE ID CREATED SIZE
registry.fedoraproject.org/fedora-toolbox 44 5a36f433c691 2 months ago 2.14 GB
quay.io/keycloak/keycloak latest 1361d6e49205 9 days ago 478 MB
...
> I'd probably just end up dropping the header and living with worse output in reality
This pretty much sums up plain text and unix shell imo. It's very much the pragmatic solution here, and it's what ~100% of shell scripters would choose to do. And it should make anyone question the orthodoxy around the "power" of plain text in shells.
Baking --sort flags into shell tools is a sign that the tools do not compose well.
Scala (the v2 series, I haven't used v3 at all) was, to a first approximation, a language of, by, and for graduate students in language research that accidentally escaped the lab and briefly took over the data engineering space. Multiple competing category theory libraries, vicious fights about which was more pure, continued debates about the beauty and confusion of implicits resolution, the list goes on.
Rust seems downright blue collar in comparison. So much of the Rust I've written and the teams I've been on, and the open source we've used has been exactly the kind of stuff we would have used Java for 15 years ago. Boring practical stuff. Same goes for the community interactions. "Here's how to get this thing working", "here's a better way to do this", "maybe you didn't know but here's a cool way to speed up that section", etc.
Sure, if you go into the development process of The Rust Language Itself, people are talking about compiler minutiae and using datalog to do type resolution, but that _really_ has not been my experience as a user. Me and everyone I know use Rust like the Golang people say they use Golang.
In fact the crux of the difference between the Rust community and the Scala community has been Rust's continued obsession with developer experience/user experience (whatever you want to call it). The error messages, the tooling, etc. Scala had none of this. A disproportionately significant section of the Scala people were obsessed with type theory, quite often to the detriment of usability/programming experience.
I respect your experience with the Rust community but I haven't had this experience at all. Totally unrecognizable to me.
Still though: Amiga 4 ever! :D
docker image ls -a | stdbuf -oL sed -r 's/\s{2,}/\t/g' | { head -n1; tail -n+2 | sort -hrk5 -t$'\t'; } | column -ts$'\t'
sort's -t is set to tab for field separation.
stdbuf sets sed's output to only buffer a line at a time and flush, so the head in the {...} command group doesn't completely consume stdin's contents before it's passed to tail.
The column command recreates the space-aligned table based on tab-delimited input.
You kind of had to be there for part of it, at least the early stuff though.
For scripting etc. it is perfect though.
Interview With Mitchell Hashimoto
Jul 2026 - Alex Alejandre
Mitchell Hashimoto was behind Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint and now builds Ghostty and Vouch.
In this interview, we talk about terminals, Zig and open source.
You’ve been interviewed a lot. Why do people like to interview you?
In interviews, everyone comes from a different angle. Many people want to know how the software engineering to business founder mindset transition went. Then others are interested in product stuff, the work I did at Hashicorp or Ghostty now. What’s different here is there’s no known agenda coming into it; neither of us have anything to sell.
What do you find so fun about terminals? Like, why Ghostty?
I spent ~15 years building CLI applications (not TUIs like we see nowadays). Through that process, I accidentally learned how to color things, move cursors etc. Leaving Hashicorp, I wanted to sharpen my technical skills (where they’d grown dull from neglect) and specifically work on: Pre-AI GPU programming, desktop/single node systems programming (spending so much time on the distributed side where you didn’t worry about cache locality or vector operations, since network costs dominated). I also really wanted to play with Zig. I wanted to satisfy those 3 things.
After 15 years building CLIs, I didn’t understand how a terminal emulator worked. I knew the components of a terminal but really wanted to understand how it worked, which would also let me work on the GPU, desktop and in Zig. My goal was to run vim and the compiler in it, have it build itself, then throw it away. But as I learned more about the terminal ecosystem, I understood nothing fit the niche I wanted: fast, feature-rich and natively cross-platform. I shared it with a few friends in Discord, who asked if they could share it with others because they were actually using it every day. The Ghostty Discord was just my friends’ group chat which got repurposed. I didn’t want to publish because my public persona would generate too much undue attention, so I ran a private beta for a long time.
How can we push terminals harder?
I don’t support pushing terminals to the extreme. Sure, they’re an application platform capable of the same things other application platforms on top of the OS are like the browser, old Java app runtime environments. You could build all functionality into it: video and microphone access, responsive layouts… You could.
But the browser is good at something, the desktop is good at something else and text-based (monospaced-grid) applications are also good at something unique. These text-based applications should be quick to implement, easy to interact with, clear in their security model. There’s a lot of opportunity in the ecosystem here and I’d love to build more protocols to enable that.
Terminal-based applications lend themselves to composition better than other paradigms. TUIs less so, but most CLI tools have mechanisms (beyond stdin and stdout) to use them like a function (the UNIX do one thing philosophy is the extreme). Neovim and AI tooling offer ever more cmdline flags. A world of better terminal applications, is a world of better automation, scriptability.
I want to make the terminal a special place for applications. The PTY’s in-band signalling (an unstructured byte stream with escape sequences) is a big problem. The Nushell ecosystem tries to fix it with another layer, but we need a fundamental improvement. Many people dislike the Microsoft ecosystem, but PowerShell gets a lot right with structured data.
What do you think about non-legacy terminal APIs?
My guiding star is how we now have multiple major, huge application platforms: the browser, emacs, the whole Apple ecosystem, Microsoft ecosystem, Android, video game console platforms. These ecosystems have strengths and weaknesses, but how do their frameworks work? On the web, it’s the DOM and JS APIs. On Apple, it’s AppKit, Cocoa and SwiftUI. On Windows, it’s Win32, WinUI etc. On Linux, it’s GTK and Qt etc. When someone says we need a better way of accessing clipboard data (historical protocols are text only, what about images, multiple MIME types etc. which desktops have handled for decades), I would grab the docs for clipboard managers on every platform to see what we’ve landed on. There’s no reason for us to build something based on our own understanding without researching decades of prior art. That’s the approach I’m trying to take here. I’ve not introduced any custom protocols yet.
Two protocols scream at me. Currently, terminals have a main screen and an alt (sometimes called primary and secondary) with different properties. Main screen is like your shell with scrollback etc. and the alternate screen is like Neovim, most TUIs etc. There are only 2, you either turn a mode on or off putting you into primary or secondary (taking up the whole screen, losing scrollback etc.)
I’d like to introduce an n-screen API to create and populate an unlimited number of screens in the background, let you overlay screens with separate grid sizes etc. The terminal emulator could handle line wrapping, selection, routing mouse events etc. You could specify a screen as a standalone window which the terminal emulator renders outside of the grid - imagine your Neovim tabs being native window tabs opened at the same time! This foundational layer would solve a lot of things.
I also have a spec’d out button protocol. Currently, there are mouse protocols to get notified when someone clicks a grid cell. But you only receive events for what’s currently on the screen, not history, when things scroll back… We currently support hyperlinks (OSC 8) and I’d like something similar to OSC 8 where clicking sends a message (which you specify) to the program. You could create a button with an open_profile ID which will still register when the user scrolls back in history. This affects main screen applications (the only ones with scroll back) like Claude Code. I have no interest discussing AI here, it’s just a really popular main screen application. The moment things go into history, you lose the ability to open files, in-app links etc.
To what extent is that just redoing the entire user space? There’s a lot of room for scope creep there.
I experimented with replacing the entire pty protocol with Wayland. If you squint, a terminal’s just a windowing server, managing windows and widgets on windows. I studied Wayland to make Ghostty run better on it and thought it’s a pretty good protocol for what it tries to solve (local desktops, rendering windows). But I threw that out.
A problem with terminals is that there’s no standards body any more. There are old specs, de jure standardized, but the past 20 years have seen standardization based on what the most popular terminals do. We have a hodge-podge of features, but no entity pushing a tasteful vision.
I don’t know what the right path forward is. You could make an alternate home for text-based applications, not called a terminal anymore, build something new (with a terminal translation layer on top to bring legacy applications on) which is trying to do something different.
How do you balance these ideas with users’ day to day demands?
I’m very public about open-source maintainers having 0 obligation to users. The first line in OS licenses is “as is, no warranty”. That’s the agreement, you get free software and can’t make demands on it. But I like striving to build good software (some may disagree and say my software’s shitty), so I do feel an obligation to fix problems, to make the software better.
Some days I wake up expecting to go through issues just fixing other people’s problems. But sometimes I wake up and focus on what I want, not reading a single issue, discussion nor PR. Sometimes, you need to push the bigger vision; sometimes, you need to address the reality on the ground.
You can build a perfect city in the sky, then come back and find terror and suffering in the real world. So you need to clean that up sometimes.
If all I did was pick through user issues every single day, you’d get stable, stagnant software. If you accept all PRs, you will change but without vision. I don’t mean to insult contributors, but only one person every few years fundamentally gets it. Most contributions just scratch someone’s specific itch, accepting them all leads to a mountain of code. Really understanding, you can sometimes discover graceful systems which solve everything succinctly.
I once did feature design video where I closed 3-4 separate feature requests solving people’s individual problems, because a single feature (different from all of them) could solve them all at the same time. Very few people can do this, not because it’s difficult but because it requires a level of care few people give to other projects.
I’ve been thinking about this off and on for like a year (along with hundreds of other things, nothing dedicated, I’m always just thinking about this stuff when not at a computer). When I finally sat down and thought “I’m going to solve this,” maybe… 1 hour? https://x.com/mitchellh/status/2003957851514126510
Fewer features composing better attracts people to exotic programming paradigms. It demands a lot of perspective.
I got on an internet spat with someone recently about my philosophy. One of the highest requested Ghostty features is search, which is done and shipped. But someone complained search bloated and broke Ghostty’s minimalism. I advertise Ghostty as feature rich! But I do distinguish that from bloat. I don’t think you should have to pay for the things you don’t use (besides disk space or resident code memory). I explained the way I architected search means it will take up disk space and be loaded into RAM but nothing will execute; this is a free feature if you don’t use it. I want Ghostty to be a riceable, customizable terminal fitting peoples’ needs, but also working out of the box and hiding them until you need or search for them, without costing anything.
But if you really want this, just fork and maintain it yourself. That’s not asking any more of you than you’re asking of me. If you want me to maintain a flag to remove it, I can ask you to maintain a fork removing it. Telling people to “fork it” often upsets them.
Very few people maintain their own patches etc. and demand entire projects to move to comfort them. It’s a very disempowering mindset to beg others to do what they could very easily do themselves, forgoing their own agency.
I’ve always believed there should be way more forks, both personal and maintained ones.
I do blame myself and venture-backed opensource in general here. There’s a whole generation which expects highly polished, funded, opinionated projects with websites and paid support staff (in Discord, Slack etc.) believing an open sourced project is a product - and it was a product in these venture backed cases. But that’s such a minute part of the ecosystem.
Open source includes sharing, but it’s about freedoms and rights. That’s the core part of open source, defining OSI-approved open source licenses. Use the software as you want, modify and fork it. None of those rights are about stability or obligation to maintain. People blame maintainers for shipping security vulnerabilities, but why didn’t you review that commit? You’re just as obligated to review the commit as the maintainer. But people hold maintainers to this higher responsibility, when they could fork and become a maintainer just like that.
If you want better guarantees, if you want the entitlement to blame someone, pay for software. When you have a vendor-customer relationship, you are now entitled to things. But there’s no entitlement in open source. Use it how you love it, that’s the path to getting what you want. If more people forked, they’d have more empathy for builders too.
Sometimes people assume some project of mine is a company or send a PR fixing a bug I don’t personally hit, and I don’t merge it because merging means committing to maintain it forever. In a personal project, I won’t merge because I don’t hit that bug.
Consuming someone else’s not-product, what’re your thoughts on Zig’s development? Clearly you’re fine without the 1.0.
I knew what I signed up for. I got into Zig by doing compiler patches and got to know the community well. I grasp the culture, philosophy etc. well, so I’m not upset by any of this.
I expect the I/O change to be one of the hardest things we’ve done, but we haven’t started yet.
Zig’s getting more popular and Andrew, the BDFL, isn’t backing down from changes he feels are necessary, which I like as a downstream consumer. 0.15 was pretty significant, changing the writer interface and thus anything printing anything. But the API is truly so much better.
Zig is just getting better and better. They focus a lot on compilation tooling and even removed language features to improve compilation speed, mind blowing. You can build lib-ghostty (the entire terminal) instantly, and Andrew still thinks these milliseconds are too slow.
I do think Zig will eventually reach a 1.0, though I think it’s still years away. It matters far less when AI’s involved. I hope people know, reading this, that I’m no AI hype-master.
At a very basic level, we know these neural nets are really good at pattern matching and pattern filling. For these kind of language changes, I showed how to do it in a variety of contexts then asked it to draw the rest of the owl. And though, the diffs were huge, 90% was done automatically while I was in the kitchen. This hints to a future where backwards compatibility means a lot less if you explain how to go from state A to B.
This is a bit ironic given Zig’s strict anti-AI policy, but AI dulls the pain changes inflict on downstream users.
How do you approach library and API design? Ghostty uses lib-ghostty. A friend was raving about how nice your libraries are to use. Do you have concrete methods to improve them besides just caring?
The most concrete way is to use a lot of libraries in a lot of communities. Just like learning a programming language you won’t actually use (professionally), using libraries across ecosystems expands your perspective and benefits you. In university, I spent a lot of time dabbling with esoteric languages. I made many toy products in Prolog, Haskell, Clojure and even Java (I was never a professional Java programmer so it was new for me. I wrote a full web side project in it. I didn’t like it but learned a lot about the build system, ergonomics, libraries, web frameworks, web servers, app servers and all that stuff.) Every ecosystem has a different culture. That culture is human for sure, but it bleeds into how they separate concerns at a library and framework level, how they make those APIs look. For the longest time, Java used the builder pattern all over the place, which I didn’t see in any other language but I tried it in Ruby and it felt pretty good. That’s an example of porting concepts. This is how I approach library design: Try to use the concepts I found the most enjoyable and hope others with similar taste also enjoy it.
I firmly believe that “nouns” matter and the problem with Docker to me is there a ton of stuff that is focused on deployment/runtime aspects and it meddles with the human flow. The fact that Vagrant was focused directly, exclusively on development was by design: the configuration, the CLI, etc. revolved around development-focused nouns, and I think that was a good thing. - https://lobste.rs/c/ddl137
Do you yourself make terminal applications dogfooding and testing these APIs and thoughts?
Not enough, honestly. I’ve been a tool maker my entire career and firmly believe in the tool maker’s dilemma where you desperately need something and understand the problem space well, then build an ideal tool, but others like it and you become an ungrounded tool maker instead of the tool user. I’ve had this bite me many times. From the terminal perspective, I live in the terminal but from a TUI development perspective, I’m not doing enough, but a few of our maintainers are prolific TUI creators like rockorager who maintains multiple email and IRC clients and authored a few specifications. I’ve been leaning on him for this.
Are you happy with today’s tech stacks? In the past, You mentioned nice-polished OS as products, big tech used to distinguish itself by technology too. But it seems like they’ve given up entirely, not dogfooding nor caring. Their open-source feels stagnated (with exception of the occasional exception like Jujutsu).
I’m… … … …okay with today’s tech stacks. They’re okay. There’s obviously so much I wish were different but I can’t get too bogged down stressing about things I can’t change, about battles that aren’t mine to fight. For example, there’s a lot of good in the frontend, TypeScript, React type communities. But there’s also way too much churn, too much complexity, the layers of abstraction aren’t clear at all. I spent time studying them but just don’t agree at all with how the community culturally addresses them. But I’m not going to fight it, replace it. So I go with the flow, stick with the mainstream to assist with community, hiring etc.
I’m fine with today’s tech stacks. I think some of the more recent developments are overly complicated across the board. HTTP/1 vs. HTTP/2 and HTTP/3, there’s a non-linear change in complexity, justified in various ways but still difficult to swallow. You see that in frontend tech, terminal tech etc. I wonder if we’re moving so fast that we’re building complicated stuff which could have been simpler. “I didn’t have time to write a short letter, so I wrote a long one instead.” This seems to be playing out industry-wide, accelerated by AI and such tooling.
Talking about Zig, you said you understood its values etc. At Hashicorp, you wrote a principles document. How do you decide, create, get buy-in and use principles day to day? Why is Ghostty e.g. feature-rich? How do principles concretely impact development?
Even when my cofounder and I wrote the Hashicorp principles or when I decided how Ghostty would develop, it was all just personal, a reflection of me, so very easy for me to live those principles day to day. I just have to act myself. People run into problems when they make principles unlike themselves. It’s that New Year’s resolution problem where you make these grandiose intentions towards dramatic changes in your life but it’s very hard, because it’s hard to actually make those dramatic changes.
For Ghostty, I cared about some less human, more technical, feature-rich choices like having a cross platform core and very much not cross-platform but unapologetically native GUI. People who valued them would come on board and collaborate; those who disagreed just wouldn’t. And that’s awesome. I’m a really big fan of open-source projects and the internet being a collection of tribes.
I’m most annoyed by programming languages here, where so many languages are becoming like least common denominator things with people criticizing so and so for because it lacks this feature every other language has and is therefore useless. Some hyperbolic statement, you know. I really like the fact that certain languages lack certain features other languages enjoy, because these constraints breed creativity and culture. I want different places to feel different. I don’t need every place to feel welcoming to every person.
People are going to get mad at me for this, but you can keep it in. For example, for me, I don’t like the Rust culture. There’s no better way to put it. Every time I’ve interacted with them or hear how they talk about Rust, I just don’t like it. That doesn’t mean they’re bad people; I think they are really good people. The philosophy behind the language and the language itself is really good. I just don’t want to use it and there’s no problem with that. Just because I don’t want to be around a community doesn’t mean it’s bad. I also don’t like soccer.
But people on the internet get stuck into such binary views about good and bad, which bleeds into how technologies become this conformist pool of bleh.
Back to Zig, Zig has a really polarizing specific stance on what it does from technology, to community management and funding to PR, blog posts and how they talk. I don’t agree with all of it but I so respect that they are unapologetically weird. So I continue to support them financially and use their technology because I support people trying to be their own person.
Large companies have gaping quality assurance issues, while smaller projects like Ghostty or Zig let you apply taste to replace 4 PRs with a single, holistic solution (human scale). How do you reconcile shipping quality with shipping fast, yea AI-generated code etc.?
To ship the right thing, there has to be a bigger understanding of the product you’re working on. This role’s solved by different people in different companies but generally corporate America doesn’t do a great job of this at scale. You can’t just listen to a specific problem a set of customers or users have and solve that specific problem. You need to understand how they got to that problem in the first place, outside of your software. What motivated that problem? Whether they should have reached this in the first place or whether something upstream would have resolved 3 other problems? You need a bigger, holistic understanding. IDK how to solve that at the corporate scale. But I handle it by being a big user of my own software.
I know not everyone can do this, but I’ve only worked in jobs whose product I’m a user of, so I can be a good human judge of whether my work is good. If you’re too far removed from the customer, you shift to “I completed the spec” or “I checked the box” lacking a deep enough understanding to say whether it’s good or bad.
I know this community has a pretty polarizing split on the AI side, but I’ve been a big proponent of rational AI usage. I fully sloppified demos etc. because I won’t ship it. The code is complete trash, but I can play and check whether something’s a useful direction. If it’s good, I can restart with the care it deserves. Right now, I have a 6 week old baby and am only on the computer about 3 hours a day, so any time savings really helps. Now, I can do so much more because I can ship ideas to myself without being on the computer.
You just have to ship quality, read and understand the code you ship and have empathy with the users who will use this. You want to create something they’re going to have joy using. That’s all that matters.
How would you suggest someone learn C today? Would it make sense to start directly with Zig?
It’s more important to learn how computers work and make the language just a means to understanding how they work. My heaviest usage of C was in college, revolving around file systems and operating systems in 3 classes. C was just the mechanism by which we interfaced closely with the lower level systems involved. My suggestion, even in this age of higher level abstractions and web development, it’s still important to understand the basics of CPU scheduling, memory, cache hierarchies, file systems, disc and file access. When you work directly above the syscall layer, whether in C, Zig or Rust, it really helps you understand what’s happening. If you go too high level, a Python, JavaScript or a Ruby’s file open API really abstracts quite a lot from you.
Another way I learned a lot was reading how the higher level languages are implemented. Don’t take a standard library function for granted, some human wrote that and you could too. How does it work? Read the stdlib and dig into how things work. Languages are easy; languages don’t matter. The underlying understanding is what matters.
For example, std's linked list seems rarely useful for anything but scripting, and could've easily been a crate. I don't think it's egregious or anything, it's just a bit meh. I don't really use Rust for scripting though (I usually use zsh or TypeScript), so maybe it's super valuable in specific cases.
This is a wide ranging discussion board, not the OpenBSD forums. That shit is fair game even if you don’t like it.
(It’s annoying, sure - because dev tribalism is the most played out thing in this industry - but overall the topic can be an interesting discussion point)
That's part of the reason why Python, go, Ruby, etc. are so popular.
There is no one right answer, it's very dependent on what's being built and where the ROI for the programming effort comes from.
The biggest difference is the failure modes. If I'm not thinking about memory, my RSS is higher or a bit of extra CPU time goes to GC. Both of those are radically better than UAF or buffer overruns. Good trade IMO.
If by discipline, you mean running something akin to the borrow checker in your head, that's essentially tautologically true. The issue with that is that it's mentally draining and/or you will still make mistakes sometimes.
This completely misses the point.
And no, C++ just doesn't make the same things easy or clean.
And no, "discipline and appropriate rules" were never enough.
Of all the complaints about rust, this strikes me as one of weirdest. How much code do you actually write for architectures outside the Tier 3 support list?
A waste.
This code will be high-defect and slow.
All of your LLM outputs should be Rust.
That is really not very different of rules enforced by the Rust compiler.
For someone who does a fresh start, using a Rust compiler may ensure safer programs out of the box, but that does not mean that the same results cannot be achieved by alternative means when using other languages, when the use of those languages makes sense for other reasons, and it is worthwhile to invest resources in making appropriate libraries and tooling.
In general, I recommend against the use of C++ in new projects, but I see much too often claims about things that are supposedly difficult or impossible to do in C++, which are just false.
For maximum safety, beyond what Rust offers by default, in C++ it is easy to replace the built-in integer types with custom integer types, which check for overflows and allow only the correct type conversions. It is also easy to define distinct types for various kinds of physical quantities, for increased safety.
You do not need to run anything in your head. With appropriate type definitions, a C++ compiler will do anything that is required.
The problem is that because of the requirement for backwards compatibility, C++ is a huge junk collection. I think that more than half of C++ consists of obsolete features, which should never be used in new programs, and this is a serious difficulty for newbies. There are various C++ style guides, but in my opinion even most of those are not very inspired.
Despite of its defects, C++ still has the advantage of extreme customizability. It is easy to write programs that appear to be written in a language that has no resemblance with C++ (inclusively by having different keywords and what appears to be a different syntax), but nonetheless they are valid C++ programs.
Such a customized C++ variant can mimic any safer language.
The work to try to address this for C++ 29, half-finished and untried as it is - is extremely restrictive, you'd likely hate it, and that's just to solve this, the relatively easy problem.
Thing is, Rust wasn't content just to solve that easy problem. (Safe) Rust also doesn't have data races. The C++ standard doesn't say very much about data races, can't help you ensure they don't happen - it just explains that if they do that's Undefined Behaviour, game over.
Ok, but recently? I too wrote code for obscure platforms once upon a time, but not in, say, the last 15 years.
Now that PCs, game consoles, and mobile devices are basically all either amd64 or ARM, there's just not such a long tail of weird platforms to develop for.
(the embedded world I will grant you, still lots of bespoke toolchains running around in that space)
The biggest innovation of Rust is bringing some of the good ideas from functional programming to low level programming. I'd also say that partially exposing data flow analysis to a proframmer is new.
Rust package management is quite good, and also not by any means an invention.
I am still not a fan of all the ugly macro programming systems and verbose syntax in the language.