I enjoy the flipside... working for a company that does provides SAAS, sometimes I find myself reminding people that we don't necessarily need a full multi-datacenter redundant deploy with logging and metrics and alerting and all this other modern stuff for a convenience service, used strictly internally, infrequently (but enough to be worth having), with effectively zero immediate consequences if it goes down for a bit.

You can take that too far, of course, and if you've got the procedures all set up you often might as well take them, but at the same time, you can blow a thousands and thousands of dollars really quickly to save yourself a minor inconvenience or two over the course of five years.

V8 gets C++-like performance when it is getting code that JITs very well. This is typically highly-numeric code, even sometimes tuned specifically for the JIT. This tends to cause a great deal of confusion when people see the benchmarks for that highly numeric code and then don't understand why their more conventional code doesn't get those speeds. It's because those speeds only apply to code you're probably not writing.

If you are writing that sort of code, then it does apply; the speed for that code is real. It's just that the performance is much more specific than people think it is. In general V8 tends to come in around the 10x-slower-than-C for general code, which means that in general it's a very fast scripting language, but in the landscape of programming languages as a whole that's middling single-thread performance and a generally bad multiprocessing story.

If the Go compiler was twice as fast, I wouldn't really notice.

If the Go linker was twice as fast, that would be a minor convenience, sometimes.

I wouldn't expect much more that twice, maybe thrice at the very outside. And it'd be a long journey to get there with bugs and such to work through. The blow-your-socks-off improvements come from when you start with scripting languages. Go may be among the slower compiled languages, but it's still a compiled language with performance in the compiled-language class; there's not a factor of 10 or 20 sitting on the table.

But having another implementation could be useful on its own merits. I haven't heard much about gccgo lately, though the project [1] seems to be getting commits still. A highly-compatible Go compiler that also did a lot of compile-time optimizations, the sort of code that may be more fun and somewhat more safe to write in Rust (though I would perceive that the challenge of such code is for the optimizations themselves to be correct rather than the optimization process not crashing, and Rust's ability to help with that is marginal). The resulting compiler would be slower but might be able to create much faster executables.

[1]: https://github.com/golang/gofrontend

Are you thinking of some sort of annotation the compiler could read and handle?

Because if a compiler starts automatically padding all my structures to put all of the members on their own cache line I'm going to be quite peeved. It would be easy for it to do, yes, but it would be wrong 99%+ of the time.

A far more trenchant complaint is that Go won't automatically sort struct members if necessary to shrink them and you have to apply a linter to get that at linting time if you want it.

This is 21st century American business. Synology wasn't going to choose their drives for maximum reliability after a long, hard, and most importantly expensive benchmarking period, they were going to stuff the cheapest drives they could buy from suppliers in there and charge more than any other drive. There's a very reasonable chance this would have produced lower quality outcomes and more support calls in the long run than random drives purchased on the open market.

Yes, this is absolutely deeply cynical, but my priors were earned the hard way, you might say.

21st century Taiwanese business.

In the end, all an optic is is a tuple of (Getter, Setter), where in a pure functional context the Setter returns a new value.

In the end, all an iterator is is a thing that returns the next value.

In the end, all a functor is is a thing that takes a value of type A and returns a value of type B.

In the end, all a reader is is a thing that yields up some bytes (or other locally appropriate type) when .Read is called.

What makes them interesting is what you can build on them and how they can compose together. None of these concepts are all that interesting on their own. Like everything else I mention above, the primary utility of lenses is that it turns an MxN problem, where you need to implement all combinations of both sides of the functionality, into an M+N problem, where you implement N combinations of things that implement the interface and you can have M users that can use that generic interface.

However, if you are not a functional programmer this will seem particularly useless to you. People often claim monads are functional programming's response to mutability, but this merely one of the many misunderstandings of the concept, that just because one particular solution to mutability uses a monadic interface then that must be the purpose of the monadic interface. Lenses are probably a much better fit for the position of "functional programming's answer to mutability". But even in FP's you only really need them if you're dealing with deeply nested structures a lot, and especially if you want to deal with those deeply nested structures polymorphically. If you don't have that problem, even in FP you probably won't reach for lenses as regular record updates can get you a long way. Records can be seen as de facto lenses that go one layer down into the relevant type automatically, and if that's all you need then you'll never need the lens library.

Thus, if you are used to mutable programming, lenses are going to seem particularly useless to you. What's the point of taking something that's nearly useless and then composing multiple of them together, when the resulting composition is also nearly useless? The real utility in lenses is their packaging up of a Setter; the Getter is pretty easy to deal with with just a normal closure. So if you don't need Setters because you're used to just mutating things in a conventional imperative language, then there's nothing there for you.

This is why you see lots of attempts to port monads into imperative languages with varying degrees of accuracy and utility into conventional languages and have probably never seen anyone try to port lenses into them.

If you are a functional programmer, then I would reiterate that comment about nested structures. I think one of the most popular uses of lenses in the Haskell community is for dealing with JSON, when you need to just deal with it directly for whatever reason and can't easily turn it into typed values because the JSON format in question is too chaotic. That's a bad JSON format and one should never from any language spec out such a thing but if you're forced to deal with someone else's chaos you have no choice.

We've actually got systems that can understand English now. Chatbots don't have to be glorified regular expression matches or based on inferior NLP. I've thought more than once that the true value of LLMs could well be that they essentially solve the language comprehension problem and that their ability to consume language is relatively underutilized compared to our attempts to get them to produce language. Under all the generative bling their language comprehension and ability to package that into something that conventional computing can understand is pretty impressive. They've even got a certain amount of common sense built in.

Yeah this seems accurate to me. All the talk of a bubble etc, but LLMs see genuinely useful at tasks like this and I'm sure we'll find more uses as time goes on.

Thank you for the belly-laugh. It's Goodhart's Law in graph form.

"Oh, is this metric important? Let me get right on that."

No shade intended towards the Ladybird team. You were given the terms and you're behaving rationally in response to them. More power to you. It's just a fantastic demonstration of what it looks like to very suddenly be developing against a very specific metric.

I think that this metric correlates well with the browser being usable on real websites

Also, I don't think that the Ladybird folks are just doing the bare minimum to only increase their score on WPT. They're implementing each feature in such a way that basic browsing seems to work better and that their WPT score improves.

The wpt score is not that well balanced. Look at https://staging.wpt.fyi/results/?product=servo&product=ladyb... : out of about 2 million tests, more than half are for the "encoding" category. Good encoding support is needed for sure, but likely not at that level of prevalence.

It seems my communication did not adequately convey the fact that I have no problem with the Ladybird team doing this. It makes perfect sense and is the right thing to do.

However, a jump like that means precisely and exactly what I said it means; very suddenly, that metric became much more important to the team. It is written straight into the graph.

A large number of encoding-related tests that were probably relatively easy to fix in bulk is certainly a plausible explanation.

A lot of people are imputing to me assumptions that they are bringing to my post, such as assuming that such improvements must be fake or bad or somehow otherwise cheating. Nope. Moreover, if you are thinking that, don't take it up with me, go take it up with the graph directly. It's not my graph. I'm just amused at the spectacular demonstration of Goodhart's Law.

Are the commentators who think I'm being critical of the Ladybird project going to defend their implicit proposition that the browser got twice as good in whatever period that graph is in, a week or a month or whatever? Of course that's not the case.

> However, a jump like that means precisely and exactly what I said it means; very suddenly, that metric became much more important to the team. It is written straight into the graph.

Not really, though. The latest jump was from implementing some CSS Typed OM features, which has been in-progress work for a while now. The 6k increase in the test score was a bit of a happy surprise. It's also not that much of a jump when you zoom out and see it's "just" a continuation of a steady increase in score over a long period.

fwiw, I'm not imputing you any assumptions. I'm just pointing out that using wpt score as a criteria is not necessarily a good proxy for browser readiness. So I'm not sure why Apple uses that, other than... there's no other objective measure? Of course it's fair game for browser engines to improve their score!

Dude at this point just raise your knickers up and criticize the thing. You’ve got the most valuable observation about this topic on your side. The graph is jarring and for someone only recently made familiar with Goodhart’s Law this is a great example of it in practice. You must be further well-informed enough to defend any issues you actually have with the project outright instead of this small war of attrition playing out waaay down here.

Too much useful insight is withheld or misappropriated these days.

While it is kinda unfortunate to have one unbalanced test suite as the major external progress indicator, there are.. like no other good options that don't involve someone manually going through like the top 1000 sites or something and checking whether they look good. That leaves having no progress indication whatsoever, which is also pretty bad.

And, in any case, implementing more of the standards is just simply good, and would need to be done at some point anyway.

I mean, sure, but can you point to any work that you think they should be doing that they're not doing because they're chasing this benchmark instead of doing whatever it is you think they should be doing?

The parallel doesn't hold, because the AI-bubble skepticism was near zero even six months ago. Yes, I was a skeptic, and I know where I was getting my info from, so I know it was not zero, but it was not a significant market force and nobody in the mainstream was issuing any cautionary notes on it.

It has now progressed to what you might call a "mainstream contrarian" position. The relevant Overton window has shifted to where it is just barely in the acceptable discourse window.

It's been a while, but if I remember my dotcom bubble, that never happened from the zero-skepticism position. It was all RAH RAH RAH and then blammo it blew apart. Skepticism was always around... again, I know because I was a skeptic and I arranged my career, with modest but far from total success, around the bubble not being sustainable, but everyone around me had no idea what I was talking about (although since my alternative was "go to grad school" I didn't get much flak since they figured the market would still be as hot years later). The skeptical position was never in the Overton window, so I don't think the comparison is useful on this particular metric.

Personally I'm watching, intrigued, to see how far the general awareness that this is a bubble can go while the bubble refuses to pop. At some point that awareness needs to translate into ceasing to feed the bubble the feedstock capital it is so rapaciously consuming, but "I can always find a bigger idiot to unload on" can run quite a ways, it seems. (I don't find that an appealing investment thesis personally but I seem to be in the minority.)

> It was all RAH RAH RAH and then blammo it blew apart. Skepticism was always around... again, I know because I was a skeptic and I arranged my career, with modest but far from total success, around the bubble not being sustainable, but everyone around me had no idea what I was talking about

There were some very prominent skeptics. Warren Buffett was regularly quoted as saying he didn't get what was going on and speculated that maybe it was time to retire.

Where I worked, people had seen tech boom and bust cycles before but what was different was the irrational exuberance wasn't just confined to a handful of stocks. Many people really did believe it was a new era and old rules didn't apply, and they were only too happy to check in on their rising Schwab and E-trade balances.

Well, ChatGPT is certainly trained on the SCP Wiki. I just fed it: "Continue this prompt: Object Class: Keter" and it spat out a perfectly-formatted SCP entry. It's not impossible that it's getting "interference" from that part of the vector space.

One of the advances I'm keeping my eye out for in AI is some sort of improvement in training capability that allows us to get some sort of AI that is roughly as capable as today's AIs but don't need to have the (metaphorical) entire Internet shoveled at them to work. A non-trivial number of alignment problems could be eliminated or mitigated if the data being fed in was small enough to be more carefully curated and the misalignments could be eliminated at the source, e.g., if we didn't feed the AIs stories about AIs going rogue and taking over the world people would have a harder time wandering into a part of the vector space where the AI starts telling that story to the user. We probably don't want the SCP wiki to be in the general training set for every AI. Some of them, by all means, but probably not all of them.

I'm 99% confident there's currently multiple companies active in the "curated LLM dataset" space, where they go through heaps of data to organize them into curated datasets for just that purpose.

But it's a huge undertaking. Google had the objective of indexing all data in the world 20-odd years ago, and that's just putting it all on a big pile; curating it is an even bigger job that can only partially be automated. Compare it with social media moderation, which is a full-time job for tens- if not hundreds of thousands of people worldwide, and that's after the automated tools have had their first pass. And that's sort-of realtime, but there's 30+ years of that to go through if you want to curate a dataset (and more if you include pre-internet media)