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).
> to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language
The runtime performance and the language are deeply linked. None of the dynamically typed runtimes you mention are actually performance competitive with JVM languages.
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.
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.
I could go on and on about the enhanced reliability features of my hybrid. One reason why it will last forever is that when the engine needs to start, the ECU grabs the crankshaft with the MGU and spins it up to 1000 RPM, and doesn't deliver fuel until oil pressure is verified. The cam phaser also keeps the valves wide open so there's little compression while starting. And, unlike other ICE engines that are forced to operate at certain speeds depending on what the car is doing, the ECU in my hybrid can detect oil dilution and simply fix it.
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.
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.
I think part of it is that most of Rust sets a really high standard for polish and good design; developers new to the language are often quite impressed by its expressiveness and by the breadth of bug classes it protects you from, once you get over the initial learning curve. (Not always—some developers never grow to like it, either because it's a bad fit for their use case or because they happen to find its particular forms of ceremony especially off-putting—but the success cases are striking.)
And then you start using async, which is less polished and has more awkward design compromises and more footguns that you only find out about at runtime, and it's a bit of a disappointment by comparison, even if some of the problems aren't worse than what you find in competing languages. This is the vibe you get in the Oxide RFDs about things like futurelock, for example.
100% agree with your take, speaking as a professional async rust writer for like five years now.
I’ll add to it that structured concurrency patterns in async Rust can be legitimately awesome and very fun, once you’ve bounced off the traits in the futures crate enough times to use it in anger. The type system can be annoying, but as usual, it’s almost always technically right, and once you understand the ownership flow required for your nifty chain of future combinators, is not too too bad.
the best async/concurrency model i know is verse [1], a language made for fortnite scripting because tim sweeney decided he wants something with "metaverse" in the name. instead of async/await or verbose callbacks its all combinators. from their docs:
# Nested blocks for complex operations
sync:
block: # Task 1 - sequential operations
LoadTexture()
ApplyTexture()
block: # Task 2 - parallel to task 1
LoadSound()
PlaySound()
LoadModel() # Task 3 - parallel to tasks 1 and 2
Funny... I started off with very little knowledge, totally cheated with what I wanted to do by cloning everything crossing various library boundaries and it still worked surprisingly well. Then I learned about (A)RC, Box etc... and I still kinda really hate the lifetime syntax.
Note: most of what I've used it for has been relatively simple... API's with tokio and axum in rust are emphatically not much more difficult than say C# with FastEndpoints, or JS/TS with Hono. It's a bit different.
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?
The initial release of dnsmasq was in 2001. The list of viable languages for a high-performance network server at the time was still not all that long. Erlang wasn't on it. Too big a performance hit, too much opaque runtime that may not have been stable at the time, too few contributors, big dependency footprint of stuff most things wouldn't have installed. (When I used Erlang for a production system in more like the 2015 time frame it still had rough corners if you weren't using it exactly for the use case it was meant for.) This isn't specially a criticism of Erlang, it would have been like this across many languages and runtimes.
A lot of these systems that are getting hit, and will probably continue to be hit over the next few weeks or months, have a similar story. The Linux kernel's only other potentially viable choice was C++ at the time. OpenSSL, a perennial security offender, was started in 1998. You can look up your own favorite major system library with major security issues and it's probably the same story.
I'm as aggressive as anyone about saying "don't write a new project in C for network access", but cast me back to 1998 and I couldn't tell you what other viable choices there are either. There are safer languages, but they were much, much smaller than the C community, and I couldn't promise you how stable they were either. Java was out, and I don't know when to draw the exact line as to when it became a serious contender for a network server, but late 200Xs would be my guess; certainly what I saw in 1999 wasn't yet.
Example: I ran a Haskell network server in 2011 for something relatively unimportant and it fell over under conditions that would not have been very extreme for a production network; I know it was Haskell and not my code because I reused the same code base in 2013 with no changes in the core run loop and it did about 90% better; still not enough that I would have put that system into a real production use case but enough to show it wasn't my code failing. So while Haskell may have existed in the 200Xs, it wouldn't have qualified as a viable choice for a network server at the time.
There's a lot more viable choices today than there used to be.
I was a language explorer and I think I hadn't heard of Ocaml by then. Even if you built the best dnsmasq project ever in Ocaml nobody would have heard of it or known how to build it.
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!
I'm not at all convinced that the highly corrosion resistant knife/tool steels you mention are actually especially high on the corrosion resistance scale -- I think they may just be excellent for a tool steel.
If you look at the knifesteelnerds article on H1 (https://knifesteelnerds.com/2019/06/24/h1-steel-how-it-works...), you'll find that it's an austentitic alloy (which is highly unusual for any sort of tool steel), and that it seems like it's likely a somewhat less corrosion resistant than usual variant on steels like 301 or 304. And the rather common stainless alloy used for non-tool applications where high levels of corrosion resistance is 316, which is more corrosion resistant than 304.
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 :)
Yes. For example, nitrogen alloyed steels like Vanax or LC200N (both of which are more corrosion resistant than the other alloys mentioned by GP) aren't particularly corrosion resistant in the total space of stainless steels, they are just very corrosion resistant as compared to how hard (and/or tough) they are.
[edit]
I should also point out that the two alloys I mentioned are not particularly hard or tough for a knife steel.
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!
> 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.
I don't disagree; I was coming from Java most recently, and a lot of the equivalents of "Sync" and "Send" were just mental notes I was making myself, and I wasn't really used to it being encoded into the type system.
Yeah, and writing thread safe Java is fraught with hidden shotgun and footguns because whether something is thread safe depends on bunch of notes about this class/method not being thread safe.
And relying on people to check them. Versus a compiler.
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.
[0] - https://ecto.hexdocs.pm/Ecto.Changeset.html
reply