Man, these are the kinds of things that I am so happy to read. People who think and care deeply about what they do, take pragmatic decisions that appears right to them and explain why they do things the way they do. Very motivating. Literally moved me from the couch to the work desk .
Unfortunately, it made me even more sad because the project I'm working on now is complete trash. Every line outdoes the previous in the dumbest thing possible. Four years at the company and not a single greenfield project for me, only well established piles of... you get the idea.
> I’ve always believed there should be way more forks, both personal and maintained ones.
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.
By making “upstreaming” the core of OS contribution, we have also failed to build tooling around downstream synchronisation. There are dedicated browser forks (a very highly complex software) that are maintained by a few volunteers. So maintaining 1 or 2 additional features depending on personal choices (or a specific company’s) shouldn’t be that hard. If we have a world where that’s normal, we will have a bigger talent pool in core tech, cloud vendors would have a hard time selling hosted solutions of open source software..etc., I think we left a good chunk of net positive impact on the table by what Mitchell mentions as the “open source project as a product” approach.
Perhaps this is one place AI could prove very helpful - automating the synchronization of forks with their parents while keeping the changes that constitute the actual fork. Or perhaps something other than forking is needed that is more diff based so you have a view of the source overlaid with the fork and the parts unchanged flow through. At least until something like Bun’s change from Zig to Rust blows your fork up completely.
I've been thinking about this as well. How can people "AI federate" their forks, without relying on a single maintainer.
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.
> maintaining a fork is roughly the same as maintaining a feature flag.
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.
> 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.
I read the full articles and always like what Mitchell trying to express, the above is an example
That's the most eloquently diplomatic way to address it. He really does have a way with words.
At the same time, it makes me a little sad that when pressed, the best thing that could be said about Zig is that it's unapologetically weird right after a sentence about not agreeing with how they manage the project.
I had high hopes for Zig, but the current situation feels like they're actively moving toward being a niche language and away from being something that I could make a case for in a business context.
> he said he does like how they manage the project.
That's the diplomatic part. He sidesteps the problems by saying that he doesn't agree with all of it (which leaves it ambiguous) but then pivots to praising the way they're unapologetic and weird.
> I don’t agree with all of it but I so respect that they are unapologetically weird.
Simplicity, and a much easier transition from C. Zig very much takes an "extend (or as they actually say: maintain) it with Zig" philosophy, rather than the classic "rewrite it in Rust". Zig integration with C rivals that of C++. Rust can do it, but it introduces a lot of friction by design, and that friction may or may not be desirable for a given project.
Do you have any examples as to how Zig is more simple than Rust?
For the most part, I find Rust to be somewhat boring once you get past the initial learning curve of the borrow checker. It's almost uneventful code and reminds me a lot of writing code in F#.
The only area that Rust feels very friction-y can be with async programming, but basically no language except Erland and Elixir make that frictionless.
> Do you have any examples as to how Zig is more simple than Rust?
On the surface: just the scale of the things you're expected to know in order to program in Zig vs the scale of things you're expected to know to program in Rust. I read the entire Zig language reference[0] in an afternoon, and then started comfortably writing Zig. I have been wanting to find time to read the Rust language reference[1] for years, but I have never carved out the time to do it, in large part because it simply demands so much more time. I end up just limping along looking up everything when I touch Rust.
I know you're hoping for more concrete examples though, so I'll try to give a few.
- One of the more obvious ones coming from a Zig perspective is the comptime story. Comptime in Zig is super easy, Rust macros less-so.
- In Zig, C libraries can be directly imported and C functions can be called directly. Rust requires (? maybe wants is more accurate?) bindings written in Rust.
- You mention Erlang and Elixir have frictionless async, and while they are essentially async utopias, I would put Golang not terribly far behind. The latest release of Zig introduced an async API that is very close to Golangs async API; I described the parallels in this comment[2]. Zig is certainly no Erlang, but the standard async API is quite nice, even when comparing to languages beyond the scope of ones with minimal runtimes like Rust and Zig.
It's hard for me to go into much more detail than that because I don't really have enough experience with Rust to say much more with confidence.
> 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?
I think you're mistaking text-with-structured data for structured data itself.
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
As far as I can tell, there is no way to do this in a manner that's even remotely composable. Your best bet is to basically do everything from within awk. Whatever the result would be, it certainly won't be pretty!
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:
the point is well-taken, but i do want to show the bash version just for fun:
podman image ls --all | sed 's/\s\s\+/\t/g' | tee >(head -n 1) >(tail -n +2 | sort -hrk 5) >/dev/null
this is _still_ all text, and we're relying heavily on sort to do a bunch of internal parsing and be in agreement with podman about how sizes should be formatted. also, for "real world" work, i dunno if the tee trick here has any kind of order guarantees, just that it works fine in this case. I'd probably just end up dropping the header and living with worse output in reality
Ooh, I was so hoping someone would take up the challenge! This is a far shorter answer than I had honestly thought was possible. More readable too, somehow? Great use of tee that I would never have come up with (though I hear what you say about there maybe not being ordering guarantees).
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 think that speaks to your final point, which is spot-on:
> 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.
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'
I used docker since that's what I have installed and I assume the output is equivalent.
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.
I like using column to format the table. Appending it to alloyed's command fixes their header problem.
The stdbuf to multi-command block (term.?) is a neat trick. Although, one time when I ran this, I only got a couple lines of output. No idea why and I can't replicate it, but there could be some flakiness that results from the buffering somehow?
Question: how do the ? markers on the sort and column invocations work/what do they do?
I'm not seeing any ? marks in my code. Are you referring to the instances of $'\t'? In bash (and other shells, including recent versions of the POSIX sh specification) $'...' is treated like a C-style string complete with backslash escape sequences, so $'\t' is a way to have a tab character as a part of a command argument.
Yes, the point was about doing it in a pipeline. The pipeline is the basis for composition of plain text in the unix shell. If something as basic as sorting a table is hard to do, it should make us question just how good the unix shell/plain text philosophy actually is.
Baking --sort flags into shell tools is a sign that the tools do not compose well.
I've spent some time thinking about it, and I respectfully disagree.
I don't think a `--sort` flag is a failure of composability, the producer understands image size semantics better than the sort command, you can either bake everything into sort, making it an all encompassing command or you can simplify the previous step with a sort flag.
Your original powershell command is way more verbose and complicated, and maybe that's the price to pay for composability, but I'd rather just use the `--sort` flag and not spend hours or days coming up with some other undocumented and undiscovered way of doing it, the answer is right there ready to be used.
I think my point is that it's a violation of the UNIX principle of doing one thing really well, but I don't think that is a violation of composability.
Tl;dr: Plain text's bad composability forces the dichotomy that you identify between --sort and sort. I agree with you that --sort often can be a sensible UX choice regardless, but losing out on composable middle ground is strictly a loss in terms of power and expressiveness.
Thanks for taking some time to think about it. Despite my pretty absolute wording in GP, I do think that there's nuance here. But what I want to drive home is that the tight coupling/brittleness inherent in plain text composition systematically limits composition.
What I'm not saying is that every --sort option is bad sign for composition. Like you point at, sometimes it's just a simpler UX to have such an option included with your command. As a matter of fact, you see that in PowerShell sometimes with the -Filter option on various cmdlets.
Plain text's brittleness limits composition by promoting exactly the extremes that you point at (the extremes being overloaded sort, or overloaded producer):
> the producer understands image size semantics better than the sort command, you can either bake everything into sort, making it an all encompassing command or you can simplify the previous step with a sort flag.
I think it should be obvious that baking everything into sort is a bad idea in the general case. Like you say, the producer understands the size semantics better. Moreover, the ergonomics are lousy (see comments by users alloyed and i15e).
Baking everything into --sort is bad because it limits sorting to the producer's own predefined semantics. While arguably better than relying on sort's, the producer won't always have the semantics that the user cares about. E.g. maybe the user wants to analyze the disk space used only on a certain datastore. Maybe some datastores do transparent compression and sorting should be done by physical disk usage. And so on.
These two extremes are basically your only options in a plain text world, but structured data gives you more opportunities for composition. By moving to structured data and eliminating the need for ad-hoc parsing, users and their code can operate at a higher semantic level. In particular, the loose coupling introduced by this approach gives you access to things like lambdas. You're not alone in objecting to PowerShell's verbosity. Here's a terser version that would work if podman image output structured data rather than text, thereby kinda steelmanning this position:
Basically all that has happened is that the plain text->structured parsing was dropped (again, to steelman the structured data vision) and naming conventions were made unix-y.
An alternate version if no specialized podman size command is needed and the sort cmdlet would by default look at an object's size property:
podman image ls --all |
sort -d
In many common cases, I think I agree with you that having --size on the producer is pragmatic and fast. A good UX choice. What's bad about plain text is that there is not/cannot be any middle ground between --sort and sort.
Now, tools shouldn't always oblige the user to compose. Composition is frequently not the best UX. But a shell that systematically limits composition is prima facie worse than one that promotes it. And plain text shells do indeed limit composition.
It seems the sticking point is the column headers but if you as a human take them off programmatically and put them back on mentally, it's a much easier problem.
That's definitely the pragmatic choice when working with shell and what roughly everyone does. But it's is also a UX compromise that, if needed anywhere other than the Stockholm Syndrome-ridden world of unix, would be routinely derided.
Shell and plain text are too embedded in the unix-descendant world to get rid of, and I'm not advocating for anything like that. Just trying to push back against oft-repeated maxims about the power of plain text. Structured data has lots to offer for composability, power, and UX.
I always hated powershell for the same reason, and then I read a really long retro by the guy who ran the project and it makes sense now.
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.
Powershell commands automatically format the data for you, you can pipe it to grep just fine (I do it all the time). It's just that you can also access it in a structured way if you need to. It's the best of both worlds.
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.
and new shells are developing features to handle structured data like json:
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 }
here is one to get a list of devices connected to my zerotier network
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" } }
those are not scripts saved in a file. i run these directly on the commandline. ignore the elvish syntax, focus on the ease of accessing values from the json data. those are just two examples, though i recently discovered an ls replacement that optionally outputs json, that will be interesting to use.
Great example! How do you like using elvish? Even though I am a proponent of structured data and like PowerShell a lot (mentioned in a nearby comment of mine), I use fish as my regular shell. Big fan of fish's careful focus on user experience, but would be open to trying something structured.
Slightly off topic, but it is worth being familiar with AWSCLI’s built in jmespath JSON transformation system. That saves on the need for jq in a lot of cases. Given that awscli bundles that, I generally forgive it for defaulting to JSON (especially given how deeply nested and interlinked many AWS API results are), but reasonable minds can differ. AWSCLI’s schizophrenic use (or not) of pagers for tiny results, on the other hand, is less defensible.
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.
I thought I would like Powershell but it was another big disappointment for me.
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.
This is my opinion as well. Powershell and object shells are much better and the way to go imo. Also Powershell code is fast owing to running on the .NET VM.
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've tried to learn rust of the longest time but failed, it's not the community that is the problem but the language itself. It is far from aesthetically pleasing, a child of perl and c++ meta template programming that inherited the worst traits of both.
Go and Python are my current preference, and C being an old soul mate.
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.
Reading this and Bun's Rust transition blog side by side just gives me a lot fun.
I'm a big fan of Rust, and as well as Ghostty.
Picking proper programming language is mostly about the product you are making and the problem you are solving.
My choice for my robot control system is Rust because I want zero-cost abstraction, no GC jitter, memory safety and avoid race conditions.
Then I moved my focus to AI agents and web applications, I pick TypeScript to take advantage of the whole ecosystem and no need to sync between backend and frontend codes.
I do not think products like Ghostty could benefit from Rust's memory safety feature a lot, but it do requires more attention to fight against the lifetime checker
> 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.
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.
Zealots are a problem in every community, sadly. Rust zealots are in the unfortunate position of having the tiniest bit of objective truth on their side — all else being equal, most C software would indeed benefit from being written in Rust instead. The zealots just don’t understand (or acknowledge) how “all else being equal” does all the heavy lifting.
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.
> all else being equal, most C software would indeed benefit from being written in Rust instead
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.
I think we're in violent agreement, because when I said "all else being equal", I really meant all else.
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.
> and the only reason it exists is because the author(s) found a way they liked to express that software.
In a discussion about comparing two languages, there's an implication there that they found a way they liked to express their idea in a particular language that couldn't be done in the other just as well if not better.
Doing things well in C requires a large amount of things that just don't happen if you're writing the same program in Rust. And Rust greatly enables domain-driven design that basically doesn't exist in any C program.
> Rust zealots are in the unfortunate position of having the tiniest bit of objective truth on their side — all else being equal, most C software would indeed benefit from being written in Rust instead.
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.
Yes, that's exactly my point — they're holding on to what is arguably a tiny kernel of truth, and blowing it way out of proportion. And, to be clear, "zealot" isn't meant as a compliment.
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 you don't like rust for whatever reason, use any other memory safe language. If you need more convincing that bugs and vulns are dropping let and right from decades old battle tested software, ask anyone with access to frontier ai sec models.
The "Rust Evangelism Strike Force" is so annoying and it becomes the major reason I don't want to have anything to do with the language, yes I know it's strange.
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.
Rust people: it's wrong to use a language that lacks memory safety and modern developer affordances. Do you really want to spend time debugging crashes and foist security problems on your users?
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.
If you're manually calling malloc in Rust, your code is almost certainly wrong. It might be called as an implementation detail when you create new objects, but std can generally be used as if it were managed automatically.
GC is such a mistake though, you don't have to use rust but to never have to think about memory is a disservice to the programmer. Because that is something you always should do, and if you do then GC is nothing but a hindrance.
Even if you're one of those people who believes the highest levels of performance require manual memory management (I'd disagree, but whatever), you'd do well to consider the performance of real-world GC against performance of the Arc/Box/dyn/clone-heavy "high-level Rust" [1] [2] that people and LLMs usually write.
Maybe you can write a carefully-tuned arena-and-slotmap that beats the pants off any GC. GC doesn't have to compete against P99.9 systems programming excellence. It has to compete against an endless soup of Arc, Box, and clone, and it will win this match without breaking a sweat.
Why does having. GC mean not thinking about memory? I think about memory constantly in GC languages because I still want it to perform well.
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.
Which is about as convenient as opt-in types in python. Nice to have but but a poor substitute and requires much more diligence than if it was designed for it in the first place.
I also do not like the Rust culture. I think the core problem is that it is so centered around identity, and this leaks into how the arguments are presented and how "outsiders" are judged. Which your example illustrates.
I don’t really understand what you mean. How can you have a community without identity? Isn’t that just a category? i.e. “a person who uses rust” vs “a member of the rust community”. There’s nothing wrong with either one, but the latter tends to define the culture.
What would you say is a good starting point for learning Rust? I’ve been curious about it for a while, but coming from a mostly Python, I’m straight up intimidated and fear wasting time trying to learn something I won’t really ever fully be competent in…
The article had great advice on this actually. When asked how to get into C, or whether it was more advisable to learn Zig instead, Mitchell suggested that
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[...]
The official rust book (officially available free online) is the way to good. So good I purchased it when it went paperback. It's a top tier language book.
Writing a Python extension would a good way to dip your toes into Rust, and also add a useful skill to Python programming (writing performant extensions). PyO3 is the main project, and the topic has been covered in several talks at Python conferences (check Youtube).
Rust was ~70% of my last job, and the other Rust engineers there were very competent -- large volumes of high-quality, high-impact code. In my rust community interactions at the time, also interactions with my colleagues, I definitely noticed some unsavory trends. An example pattern is:
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.
Its academia. Rust is admirable for having been able interesting programming language research into a mainstream language, but this had the implication of bringing the people who did said research with it into the communities.
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)
I've been using Rust in anger since ~2018 and I guess I've had completely different experience, especially compared to what I was mostly doing before, which was Scala.
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.
Rust is becoming the chosen language for those that would have previously used Haskell, OCaml, Scala, but now get to use something with more mainstream mindshare.
It isn't very hard to find folks misusing unsafe to mean something else other than memory safety, or their own ZIO like frameworks.
Easy, some folks write Haskell or Scala in Rust, because it allows them to reach a wider mindshare.
So they write their monadic and effects frameworks in Rust instead, and use unsafe to mark methods that might be dangerous, regardless of related to possible memory corruption or not.
Rust didn’t start in academia! It was a practitioner’s pet language until Mozilla started sponsoring its development. It’s actually the exact opposite of an academic language like OCaml and Scala, which were started by researchers in universities. Rust did incorporate some academic ideas like the borrow checker and algebraic data types, but the former was already being used in a precursor language, and the latter was almost becoming mainstream (which it is now, Rust helped a lot with that but was one of several languages that had it).
I had a senior dev in my previous team who pushed to write microservices for a web SaaS in rust. We already had some in Go and it worked phenomenal. Easy to learn, write, maintain, effing fast and wonderful tooling around graphQL. His only argument was "Rust is a better language and it's memory safe". That sums up the interactions I have with rust fanboys quite well. No one in the team could do rust, the added headaches around memory safety have no benefit for services like this at all and there's no tooling or hiring benefit as well (quite the opposite I guess). There wasn't a single sensible argument to be made for rust imho. I overruled him on that of course.
It’s like that joke: I admire Jesus Christ, it’s his fan club I really can’t stand.
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.
Ghandi wasn't making a joke when he said: "I love your Christ but I hate your Christians because your Christians are unlike your Christ.". By this time Ghandi had spent some time reading about Jesus, and interacting with Christians and so this contrast will have been very stark.
> I don’t like the Rust culture. There’s no better way to put it.
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 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.
You just got a tiny taste of what Rust enthusiasts have been doing to every C++ related submission here on HN for years.
Rust is one of the safer languages, but saying that it is "the safest language" is just a baseless exaggeration.
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.
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.
The borrow checker in Rust is frankly novel. Cyclone had something somewhat similar, but not the same.
The broader ML-like type system in Rust is not novel, but the integration of the borrow checker -- and its move semantics more broadly -- with it... that form honestly is an innovation. And one I'd have a hard time living without at this point.
> 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
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.
No, I mean by using only custom types for things like arrays, strings and pointers, which do access checks and automatic memory release, and not using unsafe features like the built-in arrays, strings and pointers, or the incorrect integer type conversions inherited from C.
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.
No. C++ doesn't have a garbage collector, and it doesn't have a borrowck, as a result any reference types are subject to ordinary human error because it can't garbage collect the target objects and it doesn't know when to destroy them otherwise.
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.
The rules can be enforced by a static code checker.
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.
> I suspect that Rust will start taking over as a dominant LLM output language.
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/
I tried that, but the Rust build process was too painful, and agents seemed to burn a lot of tokens guessing how to get the code to compile. I rewrote my project in Elixir and it’s been going much more smoothly
Elixir is great, and I have recently started using it myself, but its not a substitute for Rust. Try writing device driver in Elixir, or anything CPU intensive.
> not limited to the very few architectures that rust supports
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?
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)
Not trying to derail the discussion, but the reason for me to leave the Rust ecosystem in favor of Go was also the implied culture.
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
> 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.
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.
There are many dependency horrors of Rust, especially in larger projects, but I will say I've never been particularly put off by community-maintained crates that are free to make breaking changes for correctness or flexibility. Things like `temporal-rs` feel like a huge win, even given the long tail of crates with outdated dependencies (or overly-rigid APIs, etc.), and I tend to agree with Rust's smaller standard library.
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.
There is also many compile to Go languages today, that add many befefits from the MLs with still 100% Go interrop. I would say lisette is probably the one that has most momentum right now.
Seriously. Yesterday there was a thread about a use-after-free bug in OpenBSD and despite BSD predating Rust by decades there were still people chiding the project for not using Rust (as though Rust would even protect you from all memory errors in a kernel project where you'd inevitably need to write unsafe Rust anyways!). Rust might be a fine language but it has the most toxic evangelist culture, bar none.
I read the comment that they were referring to and it wasn't even constructive conversation in the thread.
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.
“A complete derail” is doing some heavy lifting there.
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)
It's easy to hate on LLM slop code but it seems that using it for analysis only could give a C codebase a much stronger security posture. Running fable and friends could give rust-like security with C portability and familiarity.
You need to write some unsafe code in a kernel, but most of the code does not have to be, which allows you to eliminate memory unsafety from almost all code and give more scrutiny to the parts the compiler cannot guarantee for you. I don’t know though if the affected code in openbsd would have needed to be unsafe. Moving towards rust is a possible way for kernels as Linux has shown, but I guess for OpenBSD the pros and cons are different, as it’s striving for a more minimal system and has been affected far less by memory unsafety issues.
> This is just so weird to me, because I would say the same about Zig.
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.
This is a good take. I was interested in accomplishing my goals and had an interest in both Rust and Zig. Going in, Rust was already proven to meet my needs and I was exploring Zig. Everything being centered around anti-Rust and “better than Rust” without meeting my needs made it a non-starter, it got in the way of discussing the languages themselves.
When was this? I've only seen this "anti-rust" vibe in the past few weeks, guess triggered by the Bun rewrite. Zig people usually will tell you to use the right tool for the job over shilling the language or that you don't need to use it yet (if you want a stable language/documentation) the language will be there if you want to check it in a few years.
I have definitely witnessed very specific cultures around languages I really like that I generally just don't vibe with. The author creates something brilliant, but there's a cadre of early adopters that shape a political and somewhat egotistical community that rubs me wrong. Once I spot them, I don't engage with the community. And it's not even that I disagree with the politics they espouse... I'm usually on the same page, but it's just kind of exhausting and a little over the top.
I'm old-ish though and grew up apolitical, so I'm sure it's just a me problem.
In the case of Ruby, the contrast between the early community pre-Rails and what came after is astounding. Partly comes down to the personality differences between Matz and DHH, I guess. I loved the community pre-2005 and had no interest in engaging with it afterward (although I used Rails for a few personal projects).
Pretty sure you could have said the same in 1986 and I know for sure you could have in 2006. Not sure why you think people having different tastes is new.
It's not necessarily the thing that matters most to executives, who are often those making decisions, but it's always been the thing that mattered most to programmers (at least those of them who have any emotions or strong preferences toward programming languages).
Always have been. When something is your primary tool, you develop strong opinion about it. Code is notation, helping to describe solutions. Not everyone thinks and solve the same way, so strong preferences is not unusual.
Well you only talked with one single person and judge that the Zig community culture sucks? I’ve seen so many dogmatic views of those Rust apostles here on HN and Linked who think Rust is the only valuable language and all the others - Python, Go, C++ (of course) - are rubbish. I am so fed up with those snobbish views of a few Rust lovers and as much as I love the language I want to avoid those ignorant fucks.
> Well you only talked with one single person and judge that the Zig community culture sucks?
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.
I have discovered Ghostty only this year, and I have switched to it a few months ago.
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.
>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.
Is there a way to encounter an unnoticeable bug?
>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.
Boyoboyoboy. It seems that you have never heard of the concept of combinatorial explosion, which in software testing, means that due to the zillions of different execution paths, plenty of bugs, which are undetected, can still exist, and can very easily not be found by just one lone ranger using some software package, no matter how long they use it, at least within a few years.
>For decades, I have used a great number of video terminal emulators.
Were you using that great number of emulators serially, or parallely, in those decades?
If parallely, you must have spend less time on each, than "for decades" implies.
If serially, you must have spent a great number of decades to use a great number of emulators.
I use the terminal that happens to be at hand, which is usually the one that ships with the OS, or the one in VSCode. I don't have high demands on the terminal, and I don't understand what problems are there to solve, as long as it handles unicode and control sequences correctly.
Huh. I never knew that was a thing. Although sounds cool. Though if you do that, or take something like a ncurses UI, and start turning it into something nicer, at what point do you have something that's not a terminal?
But I guess there's promise in having something that's like a Jupyter notebook, but for files.
Ah yeah… it was so fun when vault wouldn't let me store a 4096bit private key because it was too long, so I had to use 2048bit one instead. Peak software engineering right there.
> I find it to be way buggier than iterm with a fraction of the features.
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).
I was experiencing daily crashes of ghostty on mac with no crash report, always during claude sessions, and after the crash, I'd lose my session. Though, now we can cmd+f to search ghostty output as of the most recent version.
If in Cloud, then go Cloud native. No reason to run Vault. But on prem, there are limited options and Vault fits the bill.
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.
You’re making it seem like fewer features is a negative, but that’s not always the case. Even for programming languages, I can think of how I semi-regularly see people lamenting that Swift got too complex, while praising Go for being a small language.
i was an early vagrant user, a long time tf user, and 3 year nomad/consul user. but have moved on. cf now for aws & gcloud cli in scripts for gcp. and eks/gke instead of nomad.
I’ve worked with people who I appreciate for their unapologetic willingness to be who they are. I might not agree with their opinions and think they’re a little extreme, but I’m glad people like them exist and enjoy seeing what they devote their time to. Based on the rest of Mitchell’s response, I think something like that is what is appreciated about Zig.
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.
Is it a competition? I wonder if the Zig people feel as though it is, because I doubt the Rust people do.
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).
> 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).
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.
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.
In computing this is almost a tradition (Commodore vs Atari vs PC, Windows vs UNIX vs MacOS). It hasn't exactly hindered progress, I'd rather call it healthy competition ;)
It doesn't and I never said anything about preferences directly. There are however culture wars, and they cause problems throughout the industry and discipline.
It feels like Zig is trying to be more like C, and Rust is trying to fill a C++ slot. I wish someone would have made something in between, or that the industry would have adopted D more, it certainly didn't help that their compiler was proprietary for so long, and then they rewrote their STD lib. D to me is one language I love fundamentally, but the ecosystem is nowhere near where it could be.
Kind of tangential to the man Rust v. Zig culture debate but:
> 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).
Kind of reeks of unreasonable expectations to me. I don't think one should expect language designers to redesign a language or introduce new features that would likely be poor fits with the overall existing language philosophy (the design and usage philosophies behind Rust and Zig are practically opposite poles). Language stewards have a responsibility to everyone in their existing user base and they have a responsibility to evolve the language in a ways that's consistent with the expectations they already established (if they want to keep their users that is). Expecting the designers to rework the language to bolt on features from some other language just for your project is kind of absurd. I think Loris's supposed response is actually correct here and probably the best response he could give, without knowing more about precisely what the requests were, how willing you were to contribute work yourself, etc.
I write rust and barely interact with the community. I used to. I spoke at the first rustconf, even. I don't really care to engage with the rust community anymore (I cut myself off entirely from most online communities tbh).
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.
Please stop spamming the same comment in multiple subthreads. Also it’s pretty clear you are applfanboysbgone and have created an alt account for this knowing what you are doing is against guidelines and are doing it anyway.
I think you'll find that out of all the pairwise combinations of language communities, there's one that stands out as having beef with a bunch of other ones. And that's not true of e.g. Haskell and OCaml (or to nothing like the same degree), so it's not just about competition for mindshare, it's about an approach to competition for mindshare.
The C++ community and the Zig community seem to get along fine, so it not about looking up at the entrenched thing or down at the new thing, many orders of magnitude there and no drama.
Python, R, and Julia folks all seem to get along.
On the frontend there are a zillion things that compile to JS and even in the big camp the frameworks are split 9 ways, you get a little heat here and there over Vercel throwing big bucks or something but it's rare, generally the Svelte people and the Astro people seem to not mind when the other one front pages or whatever.
Rust is at war with the world. Maybe it can even win but it's a weird road to walk by choice.
This is weird to me too, especially to say in the present tense in 2026.
I think I get the point about "Rust culture" (although it's too vague to agree or disagree with, probably on purpose).
But in 2026, Rust is fully a commodity language, and especially to compare it to Zig in this angle is bizarre. Even turning my stereotypes to 11 and thinking back to when I worked with a team developing Rust professionally in 2021, I'd say we got mostly ended up hiring "proglang enthusiasts" and not "Rust people." In terms of "cultural dilution" alone Zig is orders of magnitude more culty than Rust because that many fewer people use it.
This is not surprising and perhaps one of the things I respect about it. Zig is pretty minimalist and I would prefer denying my pet features over becoming design by committee.
I'm a bit curious, what features could you not do without?
> This is just so weird to me, because I would say the same about Zig.
I think you missed his point. He's arguing against homogeneity of (cyber) culture. For example, programming languages that promise to do everything.
Rust fanatics indeed can be a bit like that. Every time I see a thread here about someone building something in Zig, they storm in and start arguing 'why not rust!?'.
The fact that you don't like the zig community is healthy and not weird. Don't worry about it. You don't have to like everything and you can disagree on taste.
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.
Oh, please...if you haven't noticed the carpet bombing of rust advocacy on HN for more than 4 years and still in progress, you're deliberately not paying attention.
> 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
The Zig Evangelism Task Force has supplanted Rust as the premier hypebeast. And they'll be supplanted by the NEXT BIG THING.
> 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.
I wish they would say more. The little nushell I used was a real pleasure to work with but they seem to imply there are limitations to the approach (one more layer ?). It seems the model to emulate is powershell but what does powershell do better than nushell ? I though it was essentially the same approach
Structured data as the communication medium between shell applications is so obviously a good thing, once you've used it, the Unix way of chopping up text with flags and formatting utilities seems barbaric. PowerShell got it half-right but blundered by talking in binary blobs of .NET objects instead of structured text; it was an understandable decision given how Microsoft worked at the time, but held it back from greatness.
But it's not clear how to get from here to there; Nushell doesn't seem to be catching on. I sometimes fantasize about adding two more standard streams, stdstructin and stdstructout, to go with stdin/stdout/stderr, which by informal or formal standard would write JSON (or whatever). Then coreutils and other programs could adopt them gradually and fall back to stdin/stdout whenever encountering a program not using them, and we could have gradual migration while keeping backward compatibility.
It's so sad that Rust vs Zig has been dragged into the AI psychosis vs anti AI narratives. I feel people are taking sides or picking and choosing now based on their allegiance and religious values. What good comes out of this?
Woof. Back before rust was a thing in uni all the c++ guys shat on the newbies using java and not a real language.
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.
Rust must be a big deal. Every post about programming languages seems to mention Rust. Even C++ articles bring up Rust, and Zig articles bring up Rust. I think it's because Rust has solved some really impressive problems. But at the same time, when I read interviews where people are so intensely conscious of Rust, I can't help feeling that they've come to see Rust as having solved the problems inherent in their own languages better than they did.
> Every post about programming languages seems to mention Rust. Even C++ articles bring up Rust, and Zig articles bring up Rust.
"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.
Do you see any other examples of where technical excellence is attention grabbing? From my vantage point, when something does a great job at solving a problem better than everything else nobody spends their days trying to read about it, everyone quietly starts using it. It is undeniable that Rust gets mentioned a lot because any mention of Rust brings the clicks. It is a big deal in that sense. But something being used to compel readers into reading content suggests an emotional longing that isn't being satisfied by the technical reality.
> From my vantage point, when something does a great job at solving a problem better than everything else nobody spends their days trying to read about it, everyone quietly starts using it.
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.
What is that emotional longing, exactly? I don't really know.
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.
The last time I remember seeing the same kind of behaviour was when document databases appeared on the scene. Content creators far and wide were writing about MongoDB vs Postgres, stories about rewriting an app to be "web scale", and whatnot. It grabbed reader attention because a lot of people were feeling unsatisfied with products like Postgres (this was before it added a lot of the features we expect today), MongoDB solved a problem for a niche set of users, and so the race was on to read everything they could to try and convince themselves that MongoDB would also solve the problems they have, even where their problems were not within the small area where document databases are appropriate.
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).
Thank you, senior programmer, for sharing your valuable perspective. I'm Korean, so I've mostly studied Western culture through the curation of specific figures, which means I only knew broadly that there was a conflict between Postgres and MongoDB but I never knew the details like you do. In other words, for me it feels like reading a history book, whereas for you it feels like lived experience, so I imagine our perceptions are quite different.
'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.
Does it really matter? I don't like much of the overbearing "rust culture" but I love the language and many libraries and projects are exceptionally high quality. I also like zig, people are building cool things with it. I have far less experience with it than rust but it looks interesting. I don't really get all the culture stuff, it seems like misspent energy.
I accidentally spent last week living in libghostty without knowing it. I was using rootshell, an iOS terminal app built on it. It fixed all my Claude Code scrolling and session problems on iPad. It's the first tmux experience that's felt like a native shell to me. Totally awesome.
> The philosophy behind [Rust] and the language itself is really good. I just don’t want to use it.
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.
As a guy who writes a famous Zig project, he probably gets a lot of young, eager Rust advocates trying to sell him on it. If it's his primary experience with the community, no wonder he's fed up.
Man, these are the kinds of things that I am so happy to read. People who think and care deeply about what they do, take pragmatic decisions that appears right to them and explain why they do things the way they do. Very motivating. Literally moved me from the couch to the work desk .
Unfortunately, it made me even more sad because the project I'm working on now is complete trash. Every line outdoes the previous in the dumbest thing possible. Four years at the company and not a single greenfield project for me, only well established piles of... you get the idea.
> I’ve always believed there should be way more forks, both personal and maintained ones.
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.
By making “upstreaming” the core of OS contribution, we have also failed to build tooling around downstream synchronisation. There are dedicated browser forks (a very highly complex software) that are maintained by a few volunteers. So maintaining 1 or 2 additional features depending on personal choices (or a specific company’s) shouldn’t be that hard. If we have a world where that’s normal, we will have a bigger talent pool in core tech, cloud vendors would have a hard time selling hosted solutions of open source software..etc., I think we left a good chunk of net positive impact on the table by what Mitchell mentions as the “open source project as a product” approach.
Perhaps this is one place AI could prove very helpful - automating the synchronization of forks with their parents while keeping the changes that constitute the actual fork. Or perhaps something other than forking is needed that is more diff based so you have a view of the source overlaid with the fork and the parts unchanged flow through. At least until something like Bun’s change from Zig to Rust blows your fork up completely.
I've been thinking about this as well. How can people "AI federate" their forks, without relying on a single maintainer.
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.
You should address the point Mitchell made: maintaining a fork is roughly the same as maintaining a feature flag.
> maintaining a fork is roughly the same as maintaining a feature flag.
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.
You're right, he said the request is equivalent.
Also, take it easy, it was merely a suggestion. The interesting part was comparing a feature/flag/branch to a fork, to me.
> 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.
I read the full articles and always like what Mitchell trying to express, the above is an example
That's the most eloquently diplomatic way to address it. He really does have a way with words.
At the same time, it makes me a little sad that when pressed, the best thing that could be said about Zig is that it's unapologetically weird right after a sentence about not agreeing with how they manage the project.
I had high hopes for Zig, but the current situation feels like they're actively moving toward being a niche language and away from being something that I could make a case for in a business context.
> when pressed, the best thing that could be said about Zig is
What do you mean? We didn't really discuss technical aspects etc. and he said he does like how they manage the project.
> he said he does like how they manage the project.
That's the diplomatic part. He sidesteps the problems by saying that he doesn't agree with all of it (which leaves it ambiguous) but then pivots to praising the way they're unapologetic and weird.
> I don’t agree with all of it but I so respect that they are unapologetically weird.
The person you are replying to is on every Zig thread bashing it.
You must have me mistaken for someone else because that's not true on multiple levels.
> moving toward being a niche language and away from being something that I could make a case for in a business context
That indeed seems hard. Also, at this point in time, what would be the benefit of using Zig over Rust?
Simplicity, and a much easier transition from C. Zig very much takes an "extend (or as they actually say: maintain) it with Zig" philosophy, rather than the classic "rewrite it in Rust". Zig integration with C rivals that of C++. Rust can do it, but it introduces a lot of friction by design, and that friction may or may not be desirable for a given project.
Do you have any examples as to how Zig is more simple than Rust?
For the most part, I find Rust to be somewhat boring once you get past the initial learning curve of the borrow checker. It's almost uneventful code and reminds me a lot of writing code in F#.
The only area that Rust feels very friction-y can be with async programming, but basically no language except Erland and Elixir make that frictionless.
> Do you have any examples as to how Zig is more simple than Rust?
On the surface: just the scale of the things you're expected to know in order to program in Zig vs the scale of things you're expected to know to program in Rust. I read the entire Zig language reference[0] in an afternoon, and then started comfortably writing Zig. I have been wanting to find time to read the Rust language reference[1] for years, but I have never carved out the time to do it, in large part because it simply demands so much more time. I end up just limping along looking up everything when I touch Rust.
I know you're hoping for more concrete examples though, so I'll try to give a few.
- One of the more obvious ones coming from a Zig perspective is the comptime story. Comptime in Zig is super easy, Rust macros less-so.
- In Zig, C libraries can be directly imported and C functions can be called directly. Rust requires (? maybe wants is more accurate?) bindings written in Rust.
- You mention Erlang and Elixir have frictionless async, and while they are essentially async utopias, I would put Golang not terribly far behind. The latest release of Zig introduced an async API that is very close to Golangs async API; I described the parallels in this comment[2]. Zig is certainly no Erlang, but the standard async API is quite nice, even when comparing to languages beyond the scope of ones with minimal runtimes like Rust and Zig.
It's hard for me to go into much more detail than that because I don't really have enough experience with Rust to say much more with confidence.
[0] https://ziglang.org/documentation/0.16.0 (though it was 0.14.0 at the time I read it end to end)
[1] https://doc.rust-lang.org/1.49.0/reference/
[2] https://news.ycombinator.com/item?id=48636824
I’m curious: how did you get that link to the Rust reference? It’s to a five and a half year old version.
Oops, I found it here: https://doc.rust-lang.org/stable/reference/#rust-releases
I just assumed it was a stable link to the version being read (in this case, the latest stable version).
Ahh, interesting! Thanks.
D and Swift integrate just as easily.
Also languages do not exist in isolation, thus the question remains what product will drive Zig adoption, beyond its core community.
> D and Swift integrate just as easily.
Sure, but those languages are not Rust, which was what was asked about.
> Also languages do not exist in isolation, thus the question remains what product will drive Zig adoption, beyond its core community.
The Zig team seems to be banking on providing an excellent build system that is useful beyond applications written in Zig to fill this role.
This is the only statement I disagree with:
> 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?
I think you're mistaking text-with-structured data for structured data itself.
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]:
As far as I can tell, there is no way to do this in a manner that's even remotely composable. Your best bet is to basically do everything from within awk. Whatever the result would be, it certainly won't be pretty!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:
[0] Repurposing this from a blog post I wrote: https://www.cgl.sh/blog/posts/sh.html#this-should-be-basicthe point is well-taken, but i do want to show the bash version just for fun:
this is _still_ all text, and we're relying heavily on sort to do a bunch of internal parsing and be in agreement with podman about how sizes should be formatted. also, for "real world" work, i dunno if the tee trick here has any kind of order guarantees, just that it works fine in this case. I'd probably just end up dropping the header and living with worse output in realityOoh, I was so hoping someone would take up the challenge! This is a far shorter answer than I had honestly thought was possible. More readable too, somehow? Great use of tee that I would never have come up with (though I hear what you say about there maybe not being ordering guarantees).
Unfortunately, it's not 100% correct, due to misaligned headers:
I think that speaks to your final point, which is spot-on:> 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.
A variant:
I used docker since that's what I have installed and I assume the output is equivalent.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.
There is some cool stuff here.
I like using column to format the table. Appending it to alloyed's command fixes their header problem.
The stdbuf to multi-command block (term.?) is a neat trick. Although, one time when I ran this, I only got a couple lines of output. No idea why and I can't replicate it, but there could be some flakiness that results from the buffering somehow?
Question: how do the ? markers on the sort and column invocations work/what do they do?
I'm not seeing any ? marks in my code. Are you referring to the instances of $'\t'? In bash (and other shells, including recent versions of the POSIX sh specification) $'...' is treated like a C-style string complete with backslash escape sequences, so $'\t' is a way to have a tab character as a part of a command argument.
Oops, yes, I don't know why I mistyped a question mark. That's exactly what I was wondering, thanks.
Yes, the point was about doing it in a pipeline. The pipeline is the basis for composition of plain text in the unix shell. If something as basic as sorting a table is hard to do, it should make us question just how good the unix shell/plain text philosophy actually is.
Baking --sort flags into shell tools is a sign that the tools do not compose well.
I've spent some time thinking about it, and I respectfully disagree.
I don't think a `--sort` flag is a failure of composability, the producer understands image size semantics better than the sort command, you can either bake everything into sort, making it an all encompassing command or you can simplify the previous step with a sort flag.
Your original powershell command is way more verbose and complicated, and maybe that's the price to pay for composability, but I'd rather just use the `--sort` flag and not spend hours or days coming up with some other undocumented and undiscovered way of doing it, the answer is right there ready to be used.
I think my point is that it's a violation of the UNIX principle of doing one thing really well, but I don't think that is a violation of composability.
Tl;dr: Plain text's bad composability forces the dichotomy that you identify between --sort and sort. I agree with you that --sort often can be a sensible UX choice regardless, but losing out on composable middle ground is strictly a loss in terms of power and expressiveness.
Thanks for taking some time to think about it. Despite my pretty absolute wording in GP, I do think that there's nuance here. But what I want to drive home is that the tight coupling/brittleness inherent in plain text composition systematically limits composition.
What I'm not saying is that every --sort option is bad sign for composition. Like you point at, sometimes it's just a simpler UX to have such an option included with your command. As a matter of fact, you see that in PowerShell sometimes with the -Filter option on various cmdlets.
Plain text's brittleness limits composition by promoting exactly the extremes that you point at (the extremes being overloaded sort, or overloaded producer):
> the producer understands image size semantics better than the sort command, you can either bake everything into sort, making it an all encompassing command or you can simplify the previous step with a sort flag.
I think it should be obvious that baking everything into sort is a bad idea in the general case. Like you say, the producer understands the size semantics better. Moreover, the ergonomics are lousy (see comments by users alloyed and i15e).
Baking everything into --sort is bad because it limits sorting to the producer's own predefined semantics. While arguably better than relying on sort's, the producer won't always have the semantics that the user cares about. E.g. maybe the user wants to analyze the disk space used only on a certain datastore. Maybe some datastores do transparent compression and sorting should be done by physical disk usage. And so on.
These two extremes are basically your only options in a plain text world, but structured data gives you more opportunities for composition. By moving to structured data and eliminating the need for ad-hoc parsing, users and their code can operate at a higher semantic level. In particular, the loose coupling introduced by this approach gives you access to things like lambdas. You're not alone in objecting to PowerShell's verbosity. Here's a terser version that would work if podman image output structured data rather than text, thereby kinda steelmanning this position:
Basically all that has happened is that the plain text->structured parsing was dropped (again, to steelman the structured data vision) and naming conventions were made unix-y.An alternate version if no specialized podman size command is needed and the sort cmdlet would by default look at an object's size property:
In many common cases, I think I agree with you that having --size on the producer is pragmatic and fast. A good UX choice. What's bad about plain text is that there is not/cannot be any middle ground between --sort and sort.Now, tools shouldn't always oblige the user to compose. Composition is frequently not the best UX. But a shell that systematically limits composition is prima facie worse than one that promotes it. And plain text shells do indeed limit composition.
Sorry for the essay.
It seems the sticking point is the column headers but if you as a human take them off programmatically and put them back on mentally, it's a much easier problem.
That's definitely the pragmatic choice when working with shell and what roughly everyone does. But it's is also a UX compromise that, if needed anywhere other than the Stockholm Syndrome-ridden world of unix, would be routinely derided.
Shell and plain text are too embedded in the unix-descendant world to get rid of, and I'm not advocating for anything like that. Just trying to push back against oft-repeated maxims about the power of plain text. Structured data has lots to offer for composability, power, and UX.
I always hated powershell for the same reason, and then I read a really long retro by the guy who ran the project and it makes sense now.
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.
Ooo... Any chance you remember where you read that? I'd love a reference to check it out. Sounds interesting!
I'm pretty sure they're referring to this one: https://corecursive.com/building-powershell-with-jeffrey-sno...
Thanks for sharing that. It's relevant but also a great story about how to struggle against giant corporation bureaucracy and ship against all odds
That's the one!
Powershell commands automatically format the data for you, you can pipe it to grep just fine (I do it all the time). It's just that you can also access it in a structured way if you need to. It's the best of both worlds.
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.
and new shells are developing features to handle structured data like json:
here is an elvish shell command that converts a freetube playlist from json into a list of urls grouped by author:
here is one to get a list of devices connected to my zerotier network those are not scripts saved in a file. i run these directly on the commandline. ignore the elvish syntax, focus on the ease of accessing values from the json data. those are just two examples, though i recently discovered an ls replacement that optionally outputs json, that will be interesting to use.Great example! How do you like using elvish? Even though I am a proponent of structured data and like PowerShell a lot (mentioned in a nearby comment of mine), I use fish as my regular shell. Big fan of fish's careful focus on user experience, but would be open to trying something structured.
I'ma huge fan of `fish` myself, but I've been watching `elvish` for a while now, and some of their scripting stuff really is awfully nice.
Interesting. That's a lot to type on the fly, but I can posit some benefits.
Slightly off topic, but it is worth being familiar with AWSCLI’s built in jmespath JSON transformation system. That saves on the need for jq in a lot of cases. Given that awscli bundles that, I generally forgive it for defaulting to JSON (especially given how deeply nested and interlinked many AWS API results are), but reasonable minds can differ. AWSCLI’s schizophrenic use (or not) of pagers for tiny results, on the other hand, is less defensible.
I'm not sure I agree.
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.
I thought I would like Powershell but it was another big disappointment for me.
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.
This is my opinion as well. Powershell and object shells are much better and the way to go imo. Also Powershell code is fast owing to running on the .NET VM.
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.
Related from 13h ago:
"My thoughts on the Bun Rust rewrite" by Zig's author Andrew Kelley
https://news.ycombinator.com/item?id=48843352
And for those interested in Mitchell's take on it: https://x.com/mitchellh/status/2075261972061594106?s=20.
TL;DR: No comment.
That's the only right take, no need to make a comment on someone else expressing their opinion
https://nitter.net/mitchellh/status/2075261972061594106?s=20
I've tried to learn rust of the longest time but failed, it's not the community that is the problem but the language itself. It is far from aesthetically pleasing, a child of perl and c++ meta template programming that inherited the worst traits of both.
Go and Python are my current preference, and C being an old soul mate.
> C being an old soul mate.
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.
I'd like to try out Odin and also Inko, which looks like Rust and Go had a baby. https://inko-lang.org
I have often described Zig to people as a middle ground between C and Go. It sounds like you might really enjoy it.
Reading this and Bun's Rust transition blog side by side just gives me a lot fun. I'm a big fan of Rust, and as well as Ghostty. Picking proper programming language is mostly about the product you are making and the problem you are solving. My choice for my robot control system is Rust because I want zero-cost abstraction, no GC jitter, memory safety and avoid race conditions. Then I moved my focus to AI agents and web applications, I pick TypeScript to take advantage of the whole ecosystem and no need to sync between backend and frontend codes. I do not think products like Ghostty could benefit from Rust's memory safety feature a lot, but it do requires more attention to fight against the lifetime checker
> 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.
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.
Zealots are a problem in every community, sadly. Rust zealots are in the unfortunate position of having the tiniest bit of objective truth on their side — all else being equal, most C software would indeed benefit from being written in Rust instead. The zealots just don’t understand (or acknowledge) how “all else being equal” does all the heavy lifting.
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.
> all else being equal, most C software would indeed benefit from being written in Rust instead
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.
I think we're in violent agreement, because when I said "all else being equal", I really meant all else.
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 :)
> and the only reason it exists is because the author(s) found a way they liked to express that software.
In a discussion about comparing two languages, there's an implication there that they found a way they liked to express their idea in a particular language that couldn't be done in the other just as well if not better.
Doing things well in C requires a large amount of things that just don't happen if you're writing the same program in Rust. And Rust greatly enables domain-driven design that basically doesn't exist in any C program.
> Rust zealots are in the unfortunate position of having the tiniest bit of objective truth on their side — all else being equal, most C software would indeed benefit from being written in Rust instead.
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.
Yes, that's exactly my point — they're holding on to what is arguably a tiny kernel of truth, and blowing it way out of proportion. And, to be clear, "zealot" isn't meant as a compliment.
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 you don't like rust for whatever reason, use any other memory safe language. If you need more convincing that bugs and vulns are dropping let and right from decades old battle tested software, ask anyone with access to frontier ai sec models.
I've had rust developers quite often..tell me that it's immoral to use a language that doesn't have memory safety
The "Rust Evangelism Strike Force" is so annoying and it becomes the major reason I don't want to have anything to do with the language, yes I know it's strange.
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.
Rust people: it's wrong to use a language that lacks memory safety and modern developer affordances. Do you really want to spend time debugging crashes and foist security problems on your users?
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.
If you're manually calling malloc in Rust, your code is almost certainly wrong. It might be called as an implementation detail when you create new objects, but std can generally be used as if it were managed automatically.
I'm using malloc as synecdoche for all forms of allocation, including Arc<Box<T>> stuff.
GC is such a mistake though, you don't have to use rust but to never have to think about memory is a disservice to the programmer. Because that is something you always should do, and if you do then GC is nothing but a hindrance.
For scripting etc. it is perfect though.
Even if you're one of those people who believes the highest levels of performance require manual memory management (I'd disagree, but whatever), you'd do well to consider the performance of real-world GC against performance of the Arc/Box/dyn/clone-heavy "high-level Rust" [1] [2] that people and LLMs usually write.
Maybe you can write a carefully-tuned arena-and-slotmap that beats the pants off any GC. GC doesn't have to compete against P99.9 systems programming excellence. It has to compete against an endless soup of Arc, Box, and clone, and it will win this match without breaking a sweat.
[1] https://hamy.xyz/blog/2026-01_high-level-rust
[2] https://llogiq.github.io/2020/05/30/hi.html
Performance is not even a factor in my argument.
Why does having. GC mean not thinking about memory? I think about memory constantly in GC languages because I still want it to perform well.
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.
I didn't say that. But if you think about memory then GC does more harm than good because you have no help from the language.
A GC is not the only fix for UAF and buffer overruns...
Depends very much which programming languages we're talking about.
There are enough managed languages with knobs allowing to do C like coding when required to do so.
Which is about as convenient as opt-in types in python. Nice to have but but a poor substitute and requires much more diligence than if it was designed for it in the first place.
That really, really depends on the language.
It is perfectly convenient across D, Modula-2+, Modula-3, C#, Nim, Swift, Oberon, C++/CLI, and plenty others.
For a lot of programming tasks, HAVING to think about memory is a disservice.
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.
For some tasks, sure.
But you still have to think about memory in those languages.
[dead]
I also do not like the Rust culture. I think the core problem is that it is so centered around identity, and this leaks into how the arguments are presented and how "outsiders" are judged. Which your example illustrates.
I don’t really understand what you mean. How can you have a community without identity? Isn’t that just a category? i.e. “a person who uses rust” vs “a member of the rust community”. There’s nothing wrong with either one, but the latter tends to define the culture.
What would you say is a good starting point for learning Rust? I’ve been curious about it for a while, but coming from a mostly Python, I’m straight up intimidated and fear wasting time trying to learn something I won’t really ever fully be competent in…
The article had great advice on this actually. When asked how to get into C, or whether it was more advisable to learn Zig instead, Mitchell suggested that
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[...]
The official rust book (officially available free online) is the way to good. So good I purchased it when it went paperback. It's a top tier language book.
Writing a Python extension would a good way to dip your toes into Rust, and also add a useful skill to Python programming (writing performant extensions). PyO3 is the main project, and the topic has been covered in several talks at Python conferences (check Youtube).
It does need quite a bit of time to be productive with... That being said, Rust by Example is good
Rust was ~70% of my last job, and the other Rust engineers there were very competent -- large volumes of high-quality, high-impact code. In my rust community interactions at the time, also interactions with my colleagues, I definitely noticed some unsavory trends. An example pattern is:
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.
Its academia. Rust is admirable for having been able interesting programming language research into a mainstream language, but this had the implication of bringing the people who did said research with it into the communities.
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)
I've been using Rust in anger since ~2018 and I guess I've had completely different experience, especially compared to what I was mostly doing before, which was Scala.
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.
Rust is becoming the chosen language for those that would have previously used Haskell, OCaml, Scala, but now get to use something with more mainstream mindshare.
It isn't very hard to find folks misusing unsafe to mean something else other than memory safety, or their own ZIO like frameworks.
Not sure I understand the point you're trying to make. Can you rephrase?
Easy, some folks write Haskell or Scala in Rust, because it allows them to reach a wider mindshare.
So they write their monadic and effects frameworks in Rust instead, and use unsafe to mark methods that might be dangerous, regardless of related to possible memory corruption or not.
Rust didn’t start in academia! It was a practitioner’s pet language until Mozilla started sponsoring its development. It’s actually the exact opposite of an academic language like OCaml and Scala, which were started by researchers in universities. Rust did incorporate some academic ideas like the borrow checker and algebraic data types, but the former was already being used in a precursor language, and the latter was almost becoming mainstream (which it is now, Rust helped a lot with that but was one of several languages that had it).
I had a senior dev in my previous team who pushed to write microservices for a web SaaS in rust. We already had some in Go and it worked phenomenal. Easy to learn, write, maintain, effing fast and wonderful tooling around graphQL. His only argument was "Rust is a better language and it's memory safe". That sums up the interactions I have with rust fanboys quite well. No one in the team could do rust, the added headaches around memory safety have no benefit for services like this at all and there's no tooling or hiring benefit as well (quite the opposite I guess). There wasn't a single sensible argument to be made for rust imho. I overruled him on that of course.
It’s like that joke: I admire Jesus Christ, it’s his fan club I really can’t stand.
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.
Ghandi wasn't making a joke when he said: "I love your Christ but I hate your Christians because your Christians are unlike your Christ.". By this time Ghandi had spent some time reading about Jesus, and interacting with Christians and so this contrast will have been very stark.
You are exactly depicting the problem of the rust culture.
I just think it'a visually unappealing language.
This description sounds like a cult.
[dead]
> I don’t like the Rust culture. There’s no better way to put it.
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 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.
You just got a tiny taste of what Rust enthusiasts have been doing to every C++ related submission here on HN for years.
> You just got a tiny taste of what Rust enthusiasts have been doing to every C++ related submission
Which is what C++ enthusiasts have done to C enthusiasts and C enthusiasts have done to assembly enthusiasts.
If people would just take the time to actually learn and appreciate the Analytical Engine they could bypass _all_ that noise...
I’m rather partial to Plankalkül actually
[flagged]
Rust is one of the safer languages, but saying that it is "the safest language" is just a baseless exaggeration.
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.
I am not a huge Rust fan but the language did bring a few practical and useful innovations, while also keeping a focus on practice.
And no, C++ just doesn't make the same things easy or clean.
And no, "discipline and appropriate rules" were never enough.
The practical and useful innovations were invented else, Rust made them mainstream.
Yes.
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.
Macros in Rust are really ergonomically terrible. Zig's approach here is way better.
The language I really want is somewhere inbetween those two languages.
The borrow checker in Rust is frankly novel. Cyclone had something somewhat similar, but not the same.
The broader ML-like type system in Rust is not novel, but the integration of the borrow checker -- and its move semantics more broadly -- with it... that form honestly is an innovation. And one I'd have a hard time living without at this point.
True! the borrow checker is a special thing. This is what i mean when i say "explicit data flow analysis".
In a way this is compiler internals exposed to a programmer.
And also one I'd like to see in more languages! Especially a simpler one, closer to C.
Cyclone would be the closest to that I guess. RIP.
> 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
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.
No, I mean by using only custom types for things like arrays, strings and pointers, which do access checks and automatic memory release, and not using unsafe features like the built-in arrays, strings and pointers, or the incorrect integer type conversions inherited from C.
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.
No. C++ doesn't have a garbage collector, and it doesn't have a borrowck, as a result any reference types are subject to ordinary human error because it can't garbage collect the target objects and it doesn't know when to destroy them otherwise.
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.
> with appropriate rules, restrictions and discipline
This completely misses the point.
The rules can be enforced by a static code checker.
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.
> I suspect that Rust will start taking over as a dominant LLM output language.
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/
I tried that, but the Rust build process was too painful, and agents seemed to burn a lot of tokens guessing how to get the code to compile. I rewrote my project in Elixir and it’s been going much more smoothly
Elixir is great, and I have recently started using it myself, but its not a substitute for Rust. Try writing device driver in Elixir, or anything CPU intensive.
I’m building a heavily parallel dataflow system. I thought Rust might be good for concurrency.
GP said nothing of what they were building. Seems pretty probable it was a web service/application rather than a device driver.
That is my point. It might be better for some use cases, but those are very different from the ones Rust is best.
You mean your LLMs had an easier time with Elixir. Do you actually know either of the two yourself?
what’s the difference
Rust will never be the dominant output by a country mile. It will be python and typescript.
> It will be python and typescript.
A waste.
This code will be high-defect and slow.
All of your LLM outputs should be Rust.
> rust? Ya it is the community
You mean ADA? I'd agree, at least gcc can compile it so it's not limited to the very few architectures that rust supports.
> not limited to the very few architectures that rust supports
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?
0 because it's not supported.
However I did write ADA and C for those.
> However I did write ADA and C for those.
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)
Oh it wasn't in my current job but it was less than 15 years ago.
Why are Rust people so insufferable?
We get it. You like Rust. It's not a panacea.
Not trying to derail the discussion, but the reason for me to leave the Rust ecosystem in favor of Go was also the implied culture.
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
> 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.
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.
As much as I'm put away by the dependency horror I've seen in many Rust projects, this is an interesting observation.
There are many dependency horrors of Rust, especially in larger projects, but I will say I've never been particularly put off by community-maintained crates that are free to make breaking changes for correctness or flexibility. Things like `temporal-rs` feel like a huge win, even given the long tail of crates with outdated dependencies (or overly-rigid APIs, etc.), and I tend to agree with Rust's smaller standard library.
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.
There is also many compile to Go languages today, that add many befefits from the MLs with still 100% Go interrop. I would say lisette is probably the one that has most momentum right now.
Seriously. Yesterday there was a thread about a use-after-free bug in OpenBSD and despite BSD predating Rust by decades there were still people chiding the project for not using Rust (as though Rust would even protect you from all memory errors in a kernel project where you'd inevitably need to write unsafe Rust anyways!). Rust might be a fine language but it has the most toxic evangelist culture, bar none.
> there were still people chiding the project for not using Rust
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.
[flagged]
You have an awful low bar for what is considered chiding, damn
Then again, your very username implies an indulgence in viewing technology through the lens of fandoms which is... weird
I read the comment that they were referring to and it wasn't even constructive conversation in the thread.
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.
“A complete derail” is doing some heavy lifting there.
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)
there's plenty of Rust posts to talk about Rust.
I come to an OpenBSD post to talk about OpenBSD. Rust isn't even really tangentially related.
Then do it in the litany of comment sub-threads and stop complaining about one that's a Rust tangent.
Welcome to forums, we've been using them for a few decades now.
Seek help.
It's easy to hate on LLM slop code but it seems that using it for analysis only could give a C codebase a much stronger security posture. Running fable and friends could give rust-like security with C portability and familiarity.
[flagged]
You're ascribing an entire community's reputation to a single person. I can find objectionable people in every community....
[flagged]
You need to write some unsafe code in a kernel, but most of the code does not have to be, which allows you to eliminate memory unsafety from almost all code and give more scrutiny to the parts the compiler cannot guarantee for you. I don’t know though if the affected code in openbsd would have needed to be unsafe. Moving towards rust is a possible way for kernels as Linux has shown, but I guess for OpenBSD the pros and cons are different, as it’s striving for a more minimal system and has been affected far less by memory unsafety issues.
The entire concept of publicity as a competition is baffling to me. Who gives a shit?
More Rust users = more Rust libraries = more Rust jobs = more places to do what you enjoy and get paid for it.
That seems like a train of thought so thin as to be anorexic. I think that many erm coding enthusiasts simply have issues with emotional regulation.
By that definition, Javascript is by far the bestest language in the world ;)
It is! It just happens to be one of the worst languages in the world too.
> This is just so weird to me, because I would say the same about Zig.
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.
Maybe it's even the other way around: different cultures and tastes give birth to different languages and community norms around them.
This is a good take. I was interested in accomplishing my goals and had an interest in both Rust and Zig. Going in, Rust was already proven to meet my needs and I was exploring Zig. Everything being centered around anti-Rust and “better than Rust” without meeting my needs made it a non-starter, it got in the way of discussing the languages themselves.
When was this? I've only seen this "anti-rust" vibe in the past few weeks, guess triggered by the Bun rewrite. Zig people usually will tell you to use the right tool for the job over shilling the language or that you don't need to use it yet (if you want a stable language/documentation) the language will be there if you want to check it in a few years.
Approximately 5 years ago
I have definitely witnessed very specific cultures around languages I really like that I generally just don't vibe with. The author creates something brilliant, but there's a cadre of early adopters that shape a political and somewhat egotistical community that rubs me wrong. Once I spot them, I don't engage with the community. And it's not even that I disagree with the politics they espouse... I'm usually on the same page, but it's just kind of exhausting and a little over the top.
I'm old-ish though and grew up apolitical, so I'm sure it's just a me problem.
In the case of Ruby, the contrast between the early community pre-Rails and what came after is astounding. Partly comes down to the personality differences between Matz and DHH, I guess. I loved the community pre-2005 and had no interest in engaging with it afterward (although I used Rails for a few personal projects).
This example is one of the more striking cases and you could write a (light) novel on the history of how it changed.
You kind of had to be there for part of it, at least the early stuff though.
The year is 2026 and the only thing about coding that matters anymore is taste.
Edit: Thought about scare quoting “taste”
Pretty sure you could have said the same in 1986 and I know for sure you could have in 2006. Not sure why you think people having different tastes is new.
People also stopped coding in 2006?
It's not necessarily the thing that matters most to executives, who are often those making decisions, but it's always been the thing that mattered most to programmers (at least those of them who have any emotions or strong preferences toward programming languages).
Always have been. When something is your primary tool, you develop strong opinion about it. Code is notation, helping to describe solutions. Not everyone thinks and solve the same way, so strong preferences is not unusual.
Different tastes are aguable the only reason why different programming languages exist. They're all Turing complete after all.
[dead]
Well you only talked with one single person and judge that the Zig community culture sucks? I’ve seen so many dogmatic views of those Rust apostles here on HN and Linked who think Rust is the only valuable language and all the others - Python, Go, C++ (of course) - are rubbish. I am so fed up with those snobbish views of a few Rust lovers and as much as I love the language I want to avoid those ignorant fucks.
> Well you only talked with one single person and judge that the Zig community culture sucks?
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.
I feel this way about most Hashi tools, they just seem massively overrated to me.
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
I have discovered Ghostty only this year, and I have switched to it a few months ago.
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.
>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.
Is there a way to encounter an unnoticeable bug?
>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.
Boyoboyoboy. It seems that you have never heard of the concept of combinatorial explosion, which in software testing, means that due to the zillions of different execution paths, plenty of bugs, which are undetected, can still exist, and can very easily not be found by just one lone ranger using some software package, no matter how long they use it, at least within a few years.
>For decades, I have used a great number of video terminal emulators.
Were you using that great number of emulators serially, or parallely, in those decades?
If parallely, you must have spend less time on each, than "for decades" implies.
If serially, you must have spent a great number of decades to use a great number of emulators.
This seems like a hastily put together comment.
I use the terminal that happens to be at hand, which is usually the one that ships with the OS, or the one in VSCode. I don't have high demands on the terminal, and I don't understand what problems are there to solve, as long as it handles unicode and control sequences correctly.
> I don't understand what problems are there to solve, as long as it handles unicode and control sequences correctly.
It turns out its not 1986 anymore, and sometimes we want to output gasp images to our terminals
We could already do that in 1986, outside UNIX.
Huh. I never knew that was a thing. Although sounds cool. Though if you do that, or take something like a ncurses UI, and start turning it into something nicer, at what point do you have something that's not a terminal?
But I guess there's promise in having something that's like a Jupyter notebook, but for files.
Yeah, I mean, a well-designed GUI is hard to beat, but for one-off tools/scripts, being able to dump images to the terminal is often really nice
That's so dismissive, the HashiCorp products were a game changer in a world that had very little, Vault and Terraform are super widely used
Ah yeah… it was so fun when vault wouldn't let me store a 4096bit private key because it was too long, so I had to use 2048bit one instead. Peak software engineering right there.
> I find it to be way buggier than iterm with a fraction of the features.
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).
I was experiencing daily crashes of ghostty on mac with no crash report, always during claude sessions, and after the crash, I'd lose my session. Though, now we can cmd+f to search ghostty output as of the most recent version.
What features from iterm do you miss? I’ve found ghostty to be more performant and aesthetically pleasing and haven’t missed anything
Vault can seem niche however it’s used a lot in high assurance environments given it is easily integrated with Thales HSMs and has FIPS compliance
>niche
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.
If in Cloud, then go Cloud native. No reason to run Vault. But on prem, there are limited options and Vault fits the bill.
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.
Oh, I never thought about the "in Cloud" part.
Yes, we always use the vault/secrets infrastructure of the respective cloud vendor.
Never used the product Vault.
Yeah, I kind of failed to realise that some (many?) companies literally build around one of the cloud vendors.
You’re making it seem like fewer features is a negative, but that’s not always the case. Even for programming languages, I can think of how I semi-regularly see people lamenting that Swift got too complex, while praising Go for being a small language.
i was an early vagrant user, a long time tf user, and 3 year nomad/consul user. but have moved on. cf now for aws & gcloud cli in scripts for gcp. and eks/gke instead of nomad.
I’ve worked with people who I appreciate for their unapologetic willingness to be who they are. I might not agree with their opinions and think they’re a little extreme, but I’m glad people like them exist and enjoy seeing what they devote their time to. Based on the rest of Mitchell’s response, I think something like that is what is appreciated about Zig.
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.
> Back then I found the Rust community had interest and respect for Zig, so the discourse was very much one sided.
In hindsight (and at risk of starting a flame war), it's easier to be magnanimous when you are winning/have won.
Is it a competition? I wonder if the Zig people feel as though it is, because I doubt the Rust people do.
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).
> 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).
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.
Culture wars are sadly one of the biggest inhibitors of progress throughout all of technology.
You could just have left off the last part of that :D
> Culture wars are sadly one of the biggest inhibitors of progress
It seems to hinge a lot on what is “culture”.
"my tribe"
Why does liking something different from you imply there's a war?
There is often a neo-tribalistic mentality.
"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.
In computing this is almost a tradition (Commodore vs Atari vs PC, Windows vs UNIX vs MacOS). It hasn't exactly hindered progress, I'd rather call it healthy competition ;)
Still though: Amiga 4 ever! :D
It doesn't and I never said anything about preferences directly. There are however culture wars, and they cause problems throughout the industry and discipline.
[flagged]
It feels like Zig is trying to be more like C, and Rust is trying to fill a C++ slot. I wish someone would have made something in between, or that the industry would have adopted D more, it certainly didn't help that their compiler was proprietary for so long, and then they rewrote their STD lib. D to me is one language I love fundamentally, but the ecosystem is nowhere near where it could be.
Meh... I dabbled a bit with D in context of the sokol-d language bindings, and IMHO it's an even bigger kitchen sink than C++.
Kind of tangential to the man Rust v. Zig culture debate but:
> 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).
Kind of reeks of unreasonable expectations to me. I don't think one should expect language designers to redesign a language or introduce new features that would likely be poor fits with the overall existing language philosophy (the design and usage philosophies behind Rust and Zig are practically opposite poles). Language stewards have a responsibility to everyone in their existing user base and they have a responsibility to evolve the language in a ways that's consistent with the expectations they already established (if they want to keep their users that is). Expecting the designers to rework the language to bolt on features from some other language just for your project is kind of absurd. I think Loris's supposed response is actually correct here and probably the best response he could give, without knowing more about precisely what the requests were, how willing you were to contribute work yourself, etc.
I write rust and barely interact with the community. I used to. I spoke at the first rustconf, even. I don't really care to engage with the rust community anymore (I cut myself off entirely from most online communities tbh).
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.
[flagged]
Please stop spamming the same comment in multiple subthreads. Also it’s pretty clear you are applfanboysbgone and have created an alt account for this knowing what you are doing is against guidelines and are doing it anyway.
I think you'll find that out of all the pairwise combinations of language communities, there's one that stands out as having beef with a bunch of other ones. And that's not true of e.g. Haskell and OCaml (or to nothing like the same degree), so it's not just about competition for mindshare, it's about an approach to competition for mindshare.
The C++ community and the Zig community seem to get along fine, so it not about looking up at the entrenched thing or down at the new thing, many orders of magnitude there and no drama.
Python, R, and Julia folks all seem to get along.
On the frontend there are a zillion things that compile to JS and even in the big camp the frameworks are split 9 ways, you get a little heat here and there over Vercel throwing big bucks or something but it's rare, generally the Svelte people and the Astro people seem to not mind when the other one front pages or whatever.
Rust is at war with the world. Maybe it can even win but it's a weird road to walk by choice.
>about how bad X is and how I could just do something different in Y
That's just engineering communities in a nutshell...
This is weird to me too, especially to say in the present tense in 2026.
I think I get the point about "Rust culture" (although it's too vague to agree or disagree with, probably on purpose).
But in 2026, Rust is fully a commodity language, and especially to compare it to Zig in this angle is bizarre. Even turning my stereotypes to 11 and thinking back to when I worked with a team developing Rust professionally in 2021, I'd say we got mostly ended up hiring "proglang enthusiasts" and not "Rust people." In terms of "cultural dilution" alone Zig is orders of magnitude more culty than Rust because that many fewer people use it.
This is not surprising and perhaps one of the things I respect about it. Zig is pretty minimalist and I would prefer denying my pet features over becoming design by committee.
I'm a bit curious, what features could you not do without?
> This is just so weird to me, because I would say the same about Zig.
I think you missed his point. He's arguing against homogeneity of (cyber) culture. For example, programming languages that promise to do everything. Rust fanatics indeed can be a bit like that. Every time I see a thread here about someone building something in Zig, they storm in and start arguing 'why not rust!?'.
The fact that you don't like the zig community is healthy and not weird. Don't worry about it. You don't have to like everything and you can disagree on taste.
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.
Oh, please...if you haven't noticed the carpet bombing of rust advocacy on HN for more than 4 years and still in progress, you're deliberately not paying attention.
[dead]
[dead]
> 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
The Zig Evangelism Task Force has supplanted Rust as the premier hypebeast. And they'll be supplanted by the NEXT BIG THING.
> 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.
I wish they would say more. The little nushell I used was a real pleasure to work with but they seem to imply there are limitations to the approach (one more layer ?). It seems the model to emulate is powershell but what does powershell do better than nushell ? I though it was essentially the same approach
Structured data as the communication medium between shell applications is so obviously a good thing, once you've used it, the Unix way of chopping up text with flags and formatting utilities seems barbaric. PowerShell got it half-right but blundered by talking in binary blobs of .NET objects instead of structured text; it was an understandable decision given how Microsoft worked at the time, but held it back from greatness.
But it's not clear how to get from here to there; Nushell doesn't seem to be catching on. I sometimes fantasize about adding two more standard streams, stdstructin and stdstructout, to go with stdin/stdout/stderr, which by informal or formal standard would write JSON (or whatever). Then coreutils and other programs could adopt them gradually and fall back to stdin/stdout whenever encountering a program not using them, and we could have gradual migration while keeping backward compatibility.
It's so sad that Rust vs Zig has been dragged into the AI psychosis vs anti AI narratives. I feel people are taking sides or picking and choosing now based on their allegiance and religious values. What good comes out of this?
It's just standard nerd drama. Nothing good comes of it but it doesn't matter at all either. Just shake your head and move on with your life.
> It's just standard nerd drama.
The elephant in the room are the trillion $ companies having a horse in this race.
Woof. Back before rust was a thing in uni all the c++ guys shat on the newbies using java and not a real language.
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.
Looking forward to Andrew Kelley interview's sequel and Jeaye's reaction to this.
Rust must be a big deal. Every post about programming languages seems to mention Rust. Even C++ articles bring up Rust, and Zig articles bring up Rust. I think it's because Rust has solved some really impressive problems. But at the same time, when I read interviews where people are so intensely conscious of Rust, I can't help feeling that they've come to see Rust as having solved the problems inherent in their own languages better than they did.
> Every post about programming languages seems to mention Rust. Even C++ articles bring up Rust, and Zig articles bring up Rust.
"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.
Do you see any other examples of where technical excellence is attention grabbing? From my vantage point, when something does a great job at solving a problem better than everything else nobody spends their days trying to read about it, everyone quietly starts using it. It is undeniable that Rust gets mentioned a lot because any mention of Rust brings the clicks. It is a big deal in that sense. But something being used to compel readers into reading content suggests an emotional longing that isn't being satisfied by the technical reality.
> From my vantage point, when something does a great job at solving a problem better than everything else nobody spends their days trying to read about it, everyone quietly starts using it.
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.
What is that emotional longing, exactly? I don't really know.
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.
The last time I remember seeing the same kind of behaviour was when document databases appeared on the scene. Content creators far and wide were writing about MongoDB vs Postgres, stories about rewriting an app to be "web scale", and whatnot. It grabbed reader attention because a lot of people were feeling unsatisfied with products like Postgres (this was before it added a lot of the features we expect today), MongoDB solved a problem for a niche set of users, and so the race was on to read everything they could to try and convince themselves that MongoDB would also solve the problems they have, even where their problems were not within the small area where document databases are appropriate.
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).
Thank you, senior programmer, for sharing your valuable perspective. I'm Korean, so I've mostly studied Western culture through the curation of specific figures, which means I only knew broadly that there was a conflict between Postgres and MongoDB but I never knew the details like you do. In other words, for me it feels like reading a history book, whereas for you it feels like lived experience, so I imagine our perceptions are quite different.
'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'm neutral. But sadly, this seems to be always the case when the unorthodox rising star emerges in the society.
[dead]
What does ghostty do better than say alacritty?
Does alacritty have, and/or work on a library that is reusable in other projects? If not, there is that to start.
Why would I need that
To embed it into an IDE?
Why would I need that
ghostty has tabs and splits for instance, alacritty is deliberately minimalistic
I don’t like the zig culture. There’s no better way to put it.
Does it really matter? I don't like much of the overbearing "rust culture" but I love the language and many libraries and projects are exceptionally high quality. I also like zig, people are building cool things with it. I have far less experience with it than rust but it looks interesting. I don't really get all the culture stuff, it seems like misspent energy.
> How can we push terminals harder?
> I don’t support pushing terminals to the extreme…
Reminds me of what Warp has become these days
I accidentally spent last week living in libghostty without knowing it. I was using rootshell, an iOS terminal app built on it. It fixed all my Claude Code scrolling and session problems on iPad. It's the first tmux experience that's felt like a native shell to me. Totally awesome.
How good is that setup to interact with agents on the go?
[dead]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
> The philosophy behind [Rust] and the language itself is really good. I just don’t want to use it.
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.
Petty? It's just a tool, people have opinions, rational or not.
The stupid thing is getting up in arms because someone said something you don't like.
As a guy who writes a famous Zig project, he probably gets a lot of young, eager Rust advocates trying to sell him on it. If it's his primary experience with the community, no wonder he's fed up.