asa400

Definitely cool about the uptime, but as I have no experience on systems like this, I'm also curious about the economics of this as a business strategy.

How do the maintenance, development, and operations costs of a system like this compare to - for sake of argument - a typical line-of-business Java system running on commodity servers you own in a DC somewhere?

Can anyone with experience in both comment?

Yeah agreed. Popular is a good first approximation, but to be more precise I think you want tools where the incentives in the community reward stability over features that require breakage, which would include languages and runtimes like Erlang and Clojure.

Neither is popular when compared to for example Python or PHP, but they both have cultures that care about stability in the core runtime and the libraries. Most folks probably don’t know that about Erlang and maybe think it’s some new whiz-bang thing, but Erlang is incredibly stable and well supported by a dedicated team that has been doing it for years and years at this point. I don’t know if Erlang will be more or less popular in 20 years but it 100% will be around and be receiving updates, I would put money on it.

Awesome, thank you for the detail.

I have literally seen this firsthand enough to consider it repeatable. I am not making up characters for effect. I have seen and worked with people who didn’t want to write tests because they thought it made them appear weak. I have seen people say they use Ruby because they “don’t want a compiler holding their hand” as if a compiler diminished them personally (I have nothing against Ruby specifically).

Programming is a young field compared to basically all the others. It is immature. It is undergoing massive change quickly. It does have an immature, barely developed theory of practice. This has weird effects, just like how other disciplines had weird quirks when they were young too. What was young medicine like?

I have a great deal of empathy and respect for programmers. Same for engineers and doctors. None are infallible. Doesn’t change my read that our (programming) culture could be better than it is in specific ways, which could result in better decision making in the aggregate.

As for your last point, I agree! I’ve worked too closely with them for there to be any mystique left. I don’t want programming to become civil engineering or medicine but I think we can learn things from how they think about quality and systems. They’ve had more practice at it.

Completely agree, having worked with engineers and scientists for a large part of my career.

Programming is still in this goofy phase as a profession/industry where lots of practitioners interpret suffering and complexity and difficulty as signals of underlying quality.

There are still large numbers of programmers who see advances in human-computer interaction and tools as basically childish, because what matters to them is the feeling of machismo they get while programming, rather than whether their efforts make their users more successful.

See the pushback against IDEs (as you said), syntax highlighting (“syntax highlighting is for children”), Rust (“_I_ know how to manage memory, everyone else is an idiot who needs to git gud”), types generally (“_I_ don’t make type errors”). Even high level languages and garbage collection were met with similar derision when they were going mainstream. There are so many examples of this throughout the history of programming.

If something is hard to do, or resulted in something impressively complex rather than something underwhelmingly simple, it must be good.

Basically, we’re still a very immature profession and it’ll take time before we shed the “the most important thing about programming is that I get to be a wizard” stuff. The users care that the bridge doesn’t fall down when they drive over it. The users don’t care whether designing the bridge made me feel powerful and wizardly because I used a crayon rather than Solidworks.

Is Datafusion related to Polars at all? I ask because you mentioned Rust integration.

Valid point, I will grant that. It's also entirely possible that accidents due to less grippy tires are not evenly distributed (for example, due to climate or geography) and that slightly worse traction is less of a problem for most of California's urban population in particular.

> You have started out with the assumption that these higher efficiency tires are worse gripping.

Generally speaking, with tires you are trading off wear, grip, efficiency, and cost, among other things (like off-road durability which is irrelevant here). When you make a tire roll more efficiently, it tends to make it perform worse at gripping the road in all sorts of conditions, especially adverse conditions like rain and snow. I am speaking in generalities because there are thousands of tires from dozens of manufacturers and this is not a law of physics, but it is generally true in practice. Tires today are worlds better than tires of 50 years ago but this is still true to a first approximation.

So yes, I am making that assumption.

> So either the manufacturer-supplied originals are more dangerous than replacement tires, or your argument is missing something.

The tires that come on your car from the factory are optimized for one thing and one thing only: for the OEM to sell you the car.

OEM tires are famously (infamously?) often worse in terms of wear and grip than the equivalent tire available aftermarket because they are cheaper to produce (bringing down sticker price), roll more efficiently (helping them hit EPA fuel economy numbers), and quieter on test drives. Having a cheaper tire that is quieter on test drives and hits EPA numbers that are competitive with comparable models helps sell the car.

Higher treadwear doesn't help the OEM sell the car because your test drive isn't long enough to drive the car for 60,000 miles let alone 600. Higher grip doesn't either, as average buyers won't notice tire grip on a 15 minute drive on dry pavement and enthusiasts will replace the tires anyway. With the exception of certain enthusiast vehicles, if running a cheaper tire from the factory gets the price of the car from $40,000 to $39,950, the OEM will do it, even if the buyer has to replace the tire 20,000 miles sooner and it doesn't grip as well on dry pavement or in rain or snow.

> The rest of your quasi-questions all would need to be evaluated to see if they are true or not... and one would hope that at least some of them were evaluated when creating the policy. You seem to be assuming they were not, without any real evidence one way or the other.

I'm not sure what makes my questions "quasi", I'm just having a friendly conversation about tires on the internet.

There's almost nothing in human history with a worse record of causing unintended consequences than government regulation, even well-intentioned (cookie banners?), so I think I say charitably with some basis in historical fact that governments have a spotty record when it comes to understanding and predicting the second-order effects of the regulations they make. I ask my questions with that understanding. And I say all this as someone who is broadly sympathetic to and often in favor of many government regulations that reduce CO2 emissions and make cars more efficient. I enjoy clean air as much as the next person.

It absolutely has good aspects, no doubt, but nothing about this is unquestionable. It’s significantly grayer due to all kinds of second order effects, even if you really believe in the problem and want to solve it.

Depends on how many more accidents worse-gripping tires cause that result in more totaled vehicles that require replacement and what people replace them with.

Depends on how much faster people have to replace these tires due to wear resulting in more baseline tire production.

Depends on how many more one-off flat tires people get that require getting a whole new set of 4 matched tires so their diffs aren’t destroyed.

Depends on whether slightly more efficient tires induce people to drive more on net because they feel like they’re using less gas.

Depends on this does or doesn’t affect how much tire material ends up in the environment and landfills.

There are so many levers one can pull on the “put less CO2 into the atmosphere” problem that it’s not at all clear that this one specific policy is worth it.

There’s also plenty of ways to make your point without stereotyping.

Toyota is infamous for offering special, nerfed versions of well-known tires on their new vehicles. You buy a Tacoma, you don’t get the Wildpeak AT4W, which is a very good all terrain tire. Instead, you get the Wildpeak AT4WA, which is a nerfed version with reduced tread depth that is quieter and more efficient than the real AT4W but less capable and wears out faster.

Apologies in advance this turned in to a bit of a rant of violent agreement.

For most places k8s is a complete boat anchor. Ends up being a huge complication and sap on product momentum. Can’t tell you how many outages I’ve seen from k8s misconfiguration and misunderstanding.

In no world would I consider k8s to be boring, I can’t understand how all of these shops have convinced themselves that k8s specifically is the level of abstraction at which they want to be interacting with their infrastructure.

I think k8s happens because a large number of devs look at Heroku-like platforms and bristle at the notion that they could ever be expected to intentionally constrain their brilliant system designs into preexisting, Heroku-style shapes. It’s ego on some level.

That, and a ton engineers are still incredibly bad at trading off hardware cost and compensation/complexity/organizational cost. “Heroku will cost us $2000/month, running k8s on our own hardware will only cost $400/month.” Ok, but your team’s total comp is costing the company on the order of $1MM/year. Is saving $1,600/month on infrastructure to spend $20k/month on dev time a good deal? This happens all the freaking time, it’s crazy how little devs value their own time.

Homelab tinkerers are essentially a non-market. They barely want to pay for the cheapest commodity hardware. Tens of individuals would buy Oxide racks or theoretical microcomputers with their own money.

I'm fluent in Rust and I find it quite enjoyable to read and write, more so than almost any other language I know. But, that's a subjective opinion, I wouldn't expect others to feel the same.

Rust probably has more to learn and is indeed probably _more difficult to learn_ than Zig in that it's simply a bigger language (which is quantifiable, even if only approximately) but difficultly of learning vs. enjoyment of reading/writing/speaking are different questions.

It's a bit like saying German is unfun to read and write. To who? To Germans?

Unfortunate how many languages with interesting stories were either glossed over or omitted entirely.

Clojure was an outright revolution against Java’s boring clumsiness, and many businesses are quietly making money with it today. Hickey even _explicitly_ comments on expertise (the OPs discussion about Rust and C++ being worth it) in the context of learning to play the violin.

Ruby declared itself as being all about “programmer happiness”, and while probably not as specifically a rebellion against Java, it attracted a ton of burnt out Java people who went on to found thousands of startups on Ruby. Ruby continues to be massive for web apps, Rails is still extremely popular compared to many alternatives.

Scala similarly to the previous examples was a Java-like with Haskell flavor that escaped an academic lab and accidentally took over the “big data” craze in the 2010s because they wrote Spark in it. If you were around then, Scala was truly hot at the time.

There are others of course but I found the examples in the OP a relatively surface level analysis of a space that has experienced an absolute explosion of diversity and novelty in the last 20 years.

Funny, this almost reads like a description of how Elm works.

How much load? How many concurrent connections? What machine? Don’t get me wrong, benchmarks like these are useful to help ballpark performance floors, but really only relevant for a given load scenario. They don’t mean a lot without context. Not an attack by the way, just feedback.

Erlang also has this capability built in. You can do all kinds of weird stuff with it, it’s great.

It's nonsense. The people who made Elixir understand Erlang and the BEAM as well as anyone on earth. Elixir and Erlang have different syntax but aren't even that semantically different. Contrast this with say, Java and Clojure. Clojure is significantly different than Java both in terms of what idiomatic code is, as well as how the average developer understands and uses their tools day-to-day. (Obviously they both run on the same VM, the JVM, which is why this comparison works.)

Elixir has some semantic "userspace"-level differences from Erlang (Elixir has protocols, macros, defaults to strings as binaries rather than strings as charlists, among other things) but they are much more similar than they are different. Both are on BEAM, both expression-based languages, both use processes for concurrency, have immutable data, use pattern matching for control flow, rely heavily on OTP, deploy with releases, share (or build on) the same datastructures, have the same performance characteristics, etc. If you know Elixir you pretty much already know Erlang modulo the time it takes to learn Erlang's syntax.

Looks great! There are some style quirks with cutoff elements in Firefox 152.0.6: https://imgur.com/a/OtnESi7

Any examples? I haven't seen this personally.

Not sure I understand the point you're trying to make. Can you rephrase?

> 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.

Ecto Changesets[0] are runtime constructs, yes. They're similar to libaries like Pydantic, if you're familiar with Python.

[0] - https://ecto.hexdocs.pm/Ecto.Changeset.html

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).