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.