> 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.
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.
I've read some of your other comments in this thread and I completely agree.
It's dismaying how many devs seem unable to distinguish poor project leadership/communication from being a bold truth-teller "telling it like it is".
This is a major project lead demonstrating that if things don't go well between him and you, he's going to retcon your whole relationship, collect gossip about your company and management style, chastise you for your life choices (taking venture capital?), talk shit about your code and your project, question your moral choices, and then publish all of it.
This insistence on "being right" is really caustic. It's just ugly.
> So pointing out that the zig code was full of bugs because the author was doing weird stuff and ignoring advice, couldn't hire/retain any good Zig devs because he mismanaged people and is the kind of guy to do a full rewrite because that's more interesting than fixing bugs or learning the old tools feels like stuff he'd want out there in the public domain.
All of what you say may be true, but the point remains: the Bun project lead can do whatever the hell he wants with his own project. There is no objectively "right" path here, in a moral sense.
People are allowed to rewrite their own software whenever they want to for whatever reasons they want, people are allowed to be "stinky managers" (Andrew's words), people are allowed to only hire people who want to work 7 days a week, people are allowed to only work on things that interest them, people are allowed to write crappy, hacky code in their project.
What business is it of Zig's that Jarred is (apparently, secondhand) a "stinky manager"? What business is it of Zig's that Jarred wants to run his own company the way he wants to?
Going after the guy's character after he decided he wanted to go a different direction is _incredibly_ petty.
It's so easy to deal with this like a professional: "Zig and Bun are no longer affiliated. I thank Jarred for his contributions to Zig over the years and wish him and the Bun project the best." or some variant of that. Bland and corporate, but who cares? It's done. Move on. Save the grousing for the DMs, keep on attracting new contributors, avoid alienating bystanders/potential contributors, build your project.
This post does nothing to burnish the reputation of the Zig project or its leadership, and in fact has the opposite effect. The message from the top is apparently "it's fine to be petty and vindictive".
Are the banks and trading firms that use e.g. Clojure/Elixir/Erlang/Python "comparative novices" or "less modern", whatever that means? These are some of the most sophisticated shops I've ever seen, doing some serious software engineering. I like static types as much as the next person and have written probably more Rust and Scala than anything else, but this seems maybe a bit of a gross generalization.
They absolutely are. Maybe not if the only thing you’re benchmarking is something completely CPU bound like signal processing/math, but they’re definitely competitive for tons of real use cases.
Is it fair to think of this as the ability for type information to be propagated in both directions, e.g. both up and down the callstack? So callees down the callstack may receive any type information the caller might have, while callers up the stack may also receive any information callees further down the stack might have? Please correct me if my understanding of what you wrote is way off base!
This framing is misleading. I'm not sure what AI has to do with any of the examples you cited. All of the examples you cited are moves - and in some cases, not even moves, as Shopify is not ditching Ruby - to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language, and no link to AI that I can see, as these companies all significantly predate LLMs.
Ruby's runtime in the early 2000's compared poorly against the JVM or the BEAM. People used Ruby then and now because it worked well to get products to market quickly. Even after a ton of investment in Ruby's implementation, the JVM and the BEAM are still better able to handle the types of high-traffic, high-concurrency workloads those companies serve, which makes them relevant to mature, high-scale companies.
Tellingly, there are dynamic language implementations that are performance-competitive with static language implementations, like Javascript's V8/Bun/Deno, Lua's LuaJIT, and Common Lisp's SBCL (among others, this is not an exclusive list).
Yeah, there’s just so much you can do (or not do, depending on how you look at it) when you have a well-integrated ~50hp electric motor and decent sized battery.
This is exactly correct, and I can't count how many times I've had to have this argument, thank you for pointing it out.
My hybrid (not a Prius, actually) doesn't have a dedicated starter motor, the traction motor starts the ICE engine. The climate control is electric and powered by the hybrid battery (with the added benefit of being able to run the A/C while the ICE engine is off). The power steering is electric so there's no hydraulic power steering pump to fail. I'm sure there's more I'm forgetting. Mechanically, it's just simpler than an ICE engine alone.
> ability to avoid high-stress operation because of the electric side of the power train.
This one is huge, also, and people always forget about it, so thank you for raising it. ICE hate being heavily loaded at low RPMs (also known as "lugging"), and the electric motors alleviate a lot of that low-end workload. It's a big win not just for efficiency, but also drivability, as almost all non-diesel engines make terrible torque low in their RPM range.
Entirely possible! I'm definitely not an expert. I own a few of these (LC200N and Magnacut) and I can confirm they've held up well in my own use of getting wet/dirty/etc. vs. other tool steels I have. Where they stack up against non-tool steels or steels not commonly used in cutlery, I couldn't say.
That said, I have heard plenty of anecdotes confirming these properties from other folks. People losing a knife in a stream or field and then finding it the following year, etc.
> In any case, this new alloy is weird -- it seems like it specifically has excellent resistance to electrochemical corrosion when it is used as an anode, which is not what people usually use stainless steel for :)
100%. Probably almost no crossover into cutlery, but super cool regardless!
No, it's not. It works. Perfect? No, absolutely not. There is plenty you could improve, plenty of rough edges you could smooth out. Stuff that caused us problems at the job I had writing low-ish level machine control services. But it's totally workable and we were able to ship working devices, especially compared to doing async stuff in other most other languages, especially the memory-unmanaged ones.
Kind of like Rust itself, a ton of people have tried it and bounced off it because they couldn't get it working in 10 minutes, and in doing so have declared it impossible/for geniuses only/broken/ecosystem-destroying. The narrative around async Rust is probably 70% meme/bad PR, 30% real, actual issues that could be improved.
I hope this comes off as fair. I don't want to excuse any of the shortcomings, but it's a working, useful tool.
For folks with more experience in this specific domain, dumb question: why is more software in this space not written in e.g. Erlang or some other garbage collected, concurrent language runtime?
Very interesting. Highly corrosion resistant "unconventional" steels have become somewhat popular in cutlery, with steels like LC200N, H1/H2, and MagnaCut. LC200N and H1/H2 in particular can be left in body of water uncoated/unpainted and come back in a year and they'll be fine. Obviously that's a different setting than electrified seawater for hydrogen production, though. So much cool materials science happening!
> having to worry about Send and Sync and Pin and fighting with the borrow checker and all that fun stuff.
To be fair, the alternative to having to worry about Send/Sync/Pin is not "not worrying about Send/Sync/Pin". It's having to worry about correctly enforcing the constraints they describe on your own, without any kind of mechanical help. E.g., not moving data to another thread that shouldn't be and not accessing data from multiple threads that shouldn't be. This stuff is intrinsic.
In this sense the Rust mental model is simpler, because failing to uphold these constraints is no longer "your fault", it's Rust's fault.
They probably won't buy Honda Civics, but they (or their children, more realistically) might buy the electric equivalent of an F150 if the market produces one that can fulfill what they perceive their needs to be.
I just bought a (small, hybrid) truck because I need to do some truck stuff. I 100% would have bought an electric if the market produced one with comparable capability and competitive price, but we're not there yet, and I don't have Rivian money (yet! lol maybe someday).
My point being: there is still a huge demand for trucks from both a capability and culture standpoint, and very little supply of a cost-comparable product that doesn't take gas or diesel. Rivian is around double what most people want to pay, and the F150 Lightning was marketed poorly and had bad towing/hauling range compared to gas/diesel equivalents.
I'm not here to defend "truck culture" but I do believe that if you offer people a better product, they will figure it out and buy it. An electric truck with 400+ miles of towing range, an onboard 2kW+ inverter, 500 ft-lbs of torque, and fast charging for the same price as a comparable gas F150 will sell. Unfortunately the battery energy density and EV supply chain economies of scale aren't there yet in North America.
> Should one accept that noone will read 99% of what one shares and just use sharing as a way to record and reflect on own process?
Yes, 100%. Almost no one has found either my public code or my writing useful, but the process of writing and documenting has been tremendously useful to help me clarify what I _actually believe_ at that point in time. This is the primary benefit.
That said, a few projects have taken off unexpectedly and clearly helped some folks, and I've received a few cold emails from folks who somehow ended up on my blog, and all have been pleasant conversations!
One thing I recommend is trying to lower the threshold of what is acceptable to publish. Publish scraps, publish "today I learned", publish "look at this stupid thing I discovered" stuff. Gradually your threshold will rise, but one mistake I see people making is the belief that they have to publish finished projects and novel-quality writing in order for it to be worth it. Nothing could be further from the truth.
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.