jjav

> Moving faster is good.

No, not necessarily. Sometimes, yes. For anything important, the last thing I want is a company that's moving too fast.

An email company? The base protocol RFC was written in the 70s. It's as mature as computer technology gets. There is zero value in moving fast here, all the value is in building an absolutely rock solid and secure solution.

The very opposite of move fast and break things.

> That's the sort of thing you really don't want to hear from your encrypted mail company.

Tone deaf award of the decade surely goes to that guy.

If it were some social game app or something, I guess it wouldn't be as tragic, but for a company whose sole reason to exist is to provide security... wow. Goodbye any trust ever again.

> Maybe not all of the projects need the same properties.

Definitely not all projects need the same level of quality.

But per the thread, if you allow the skills of all the engineers in your company to rot, what happens when there is a system that needs the higher level of quality?

> The geeks won.

For a very brief period, and then when the really big money started rolling in, all the personalities that used to flock to wall street became programmers.

The Silicon Valley of the 90s was completely different to the thing it is now here.

Insurance always wins. In the case of an event that would be unprofitable, they'll just refuse to pay.

It would, that's why a solution needs to be paired with an aggressively progressive tax system. Beyond some point, the tax rate needs to become 100% of all wealth above it.

> I have been using Emacs for more than 30 years now. Other editors have come and gone, Emacs stayed. Parts of my configuration are more than 30 years old.

Same here! Aside from the basic unix tools in /[usr]/bin/, there is very little software with the longevity of emacs. I fully switched from vi to emacs in 1992 and been using it heavily every day since then. So good.

(The only other program I can think of from that era that I still use is trn to read USENET)

Yes there are reasons to create better models. Baking in latest revision of assorted API documentation is not it.

You could simply try it. Find an API that is not publicly documented and thus not part of any training set. Take any AI model, give it the documentation and tell it to create some code that uses that API.

I'm not talking about open source, I'm talking about the risk for non-US governments to be dependent on a sole supplier to be able to function, be it Microsoft or Starlink or any US-based corporation.

> cycle of open source zealots

This is a pretty biased take. If there is anything the world is finally learning, it is that being completely dependent (not only for functionality but also availability) on a single vendor operating from a potentially uncooperative government, is not a great position to be in.

> APIs get updated and expanded, new frameworks and libraries get introduced, bugs get fixed. How long is an existing model going to still be useful?

You don't rely on the model knowing about such things up front. You feed it the latest API documentation and then work off that.

Others have answered this: licensing

Linux is the most common platform and many Linux distributions have an issue with license compatibility (or perceived one), which hinders adoption.

> Because ZFS is complicated to use

There is nothing complicated about having zfs be your filesystem. You can use its extra features like snapshots, send/receive, etc, but only if you wanted to. Otherwise it's just a filesystem, there is nothing to use as such, so nothing complicated.

> and isn’t necessary for most workloads.

Not sure what that means. What workload wouldn't benefit from a reliable filesystem?

> This is premature optimization at its finest.

Not really, this is an example (of many) where that quote is taken out of context and does not apply.

The premature optimization quote is about spending tons of time fine-tuning functions for optimal performance, shaving a millisecond here or there.

The choice of languages and/or frameworks to allow the product to reach your intended goals is a critical early architectural choice. One that is costly to revert later.

IOW, if you're building a niche SaaS app that you don't intend (or want) to market to a larger customer base then it makes sense to use a slow language if it does what you want conveniently.

OTOH, if your business plan is to scale to millions/billions of users as soon as you can get there, it is a mistake to paint yourself into a corner where you'll have to rewrite everything soon in the growth curve.

Now, perhaps, in the age of AI this matters less if you can use AI to rewrite everything when you get to that point. Although I haven't gone through an exercise of using AI to rewrite the whole company codebase at once, not sure yet how well that'll work.

Everytime a jwz link is posted on HN I click on it, and it always works fine. Like just now for the above link.