If for no other reason, this is good news in that it encourages a larger number of platforms with a diversity of information and opinions. Being centralized on any one platform serves no one except for the platform's ownership.
When they were on X, people on X had no incentive to go to other places for Guardian content. Now they do. I don't believe that they'll meaningfully change people's behaviors on their own, but's a step.
I think it's not just you, but certainly not everyone. Kotlin with Java 21+ is my go-to choice for an I/O-bound service, or really any service. It's just so ergonomic, and with virtual threads the code can be as simple and efficient as Go - while also taking advantage of possibly the best and largest library ecosystem in the world.
I'm not knocking Go or Python - if those are your preferred tools, they're more than adequate. Java, however, isn't nearly as irrelevant as you may perceive.
I mean, I share your opinion personally but plenty of people find it pleasant to read and write. If it was really a bad language, it wouldn't have the adoption it does.
This solution reminds me of an old blog post, where two members of the F# team at Microsoft battled back and forth on making the best solver for some word game. Cloudflare's solution here looks a lot like the second-to-last solution; the final post involved collapsing the tree nodes into a 2D array of u32s for maximum cache-hits. It was a really neat solution!
Maybe it's just my skill level, but I've used both hand-rolled recursive-descent and ANTLR for the same project (Thrift parser), and hoo boy I would never go back to recursive-descent for that. ANTLR shrank my code by an order of magnitude, and cleaned up some bugs too.
I'd be willing to believe that beyond a certain level of input complexity, ANTLR no longer pays for itself. In my experience, there exists a class of languages for which there's no better tool.
I would love to see the diff between the hand-rolled recursive-descent parser and the ANTLR syntax!
I certainly feel the amount of boilerplate in my hand-rolled recursive-descent parser is manageable. Of course it's not as succinct as an EBNF grammar:
- For example, you have to write an actual loop (with "for" and looping conditions) instead of just * for repetition
- The Go formatter demands a newline in most control flows
- Go is also not the most succinct language in general
So you do end up with many more lines of code. But at the end of the day, the structure of each parsing function is remarkably similar to a production rule, and for simpler ones I can mentally map between them pretty easily, with the added benefit of being able to insert code anywhere if I need something beyond old-school context-free parsing.
Wow, what a rug-pull! Good luck to Cockroach Labs, but I doubt their product is entrenched-enough to make this strategy sustainable - it's going to _kill_ growth.
For an alternative (but still very valid) interpretation, Wanda Landowska playing BWV 903 on a harpsichord in 1935 totally blew my mind: https://www.youtube.com/watch?v=h-tsbumcyVc
My piano teacher pointed me to this recording when I studied the piece with him. It was scandalizing at first, but the free improvisation in the arpeggiated chords is almost miraculous. (I also love Paul Badura-Skoda's take on the piece: https://www.youtube.com/watch?v=Xx5gojkXdeI)
I love this guy's channel! It's interesting, unpretentious, and he has such a wealth of chemical and metallurgical knowledge. The reactions and processes he shows are amazing.
Were you involved with the project? I worked at msft back then and distinctly remember the office ipad team. I think ballmer actually let them release just the OneNote standalone app in 2013 iirc.
reply