How? Morris didn’t get the job because he was born in the wrong country?

Very wealthy people have access to very exclusive and potentially unethical and/or illegal capabilities. Many do not think they are bound to the same rules as the rest of society. Some are probably not.

OpenAI the company may not be responsible, but there are elites in the OpenAI sphere who might be.

I’m curious which are the well known projects or products that have ported or converted away from Go. Anyone have a shortlist?

I have seen a lot of large projects do this but don’t keep a list. The ones that remember from recently reading about them is Discord and IndexedDB.

> why structured editors haven’t taken over the world: most programmers find them so annoying to use in some situations that they don’t view the pros as outweighing the cons.

Seems like "annoying" refers to a user interface annoyance.

I'm guessing the following since I couldn't tell what structured editing is like from the article:

Keyboard entry is immediate, but prone to breaking the program structure. Structured editing through specific commands is an abstraction on top of key entry (or mouse), both of which add a layer of resistance. Another layer might come from having to recall the commands, or if recognizing them, having to peruse a list of them, at least while learning it.

What does the developer's experience with incremental parsing feel like?

> What does the developer's experience with incremental parsing feel like?

It's essentially the experience most of us already have when using Visual Studio, IntelliJ, or any modern IDE on a daily basis.

The term "incremental parsing" might be a bit misleading. A more accurate (though wordier) term would be a "stateful parser capable of reparsing the text in parts". The core idea is that you can write text seamlessly while the editor dynamically updates local fragments of its internal representation (usually a syntax tree) in real time around the characters you're typing.

An incremental parser is one of the key components that enable modern code editors to stay responsive. It allows the editor to keep its internal syntax tree synchronized with the user's edits without needing to reparse the entire project on every keystroke. This stateful approach contrasts with stateless compilers that reparse the entire project from scratch.

This continuous (or incremental) patching of the syntax tree is what enables modern IDEs to provide features like real-time code completion, semantic highlighting, and error detection. Essentially, while you focus on writing code, the editor is constantly maintaining and updating a structural representation of your program behind the scenes.

The article's author suggests an alternative idea: instead of reparsing the syntax tree incrementally, the programmer would directly edit the syntax tree itself. In other words, you would be working with the program's structure rather than its raw textual representation.

This approach could simplify the development of code editors. The editor would primarily need to offer a GUI for tree structure editing, which might still appear as flat text for usability but would fundamentally involve structural interactions.

Whether this approach improves the end-user experience is hard to say. It feels akin to graphical programming languages, which already have a niche (e.g., visual scripting in game engines). However, the challenge lies in the interface.

The input device (keyboard) designed for natural text input and have limitations when it comes to efficiently interacting with structural data. In theory, these hurdles could be overcome with time, but for now, the bottleneck is mostly a question of UI/UX design. And as of today, we lack a clear, efficient approach to tackle this problem.

This article was kind of lazy. It’s a lot of conjecture, a couple anecdotal observations, and some rhetoric for good measure. Basically, the content was a let down from the title. On the other hand, I didn’t know Data Scientist candidates would also be tested with LeetCode questions.

“Yak” shaving of a sort!

Are you opposed to the process by which discussion can initiate a transition from negative state to positive state?

Seems healthy to me.

To me, even proposing the (extremely obviously) negative state in the first place is a sign of bad faith on the part of the proposer.

If they proposed kicking puppies twice a day, and after some discussion decided to not do that would we all be applauding their decision?

Ridiculous. Only you believe those two are equivalent.

I don't believe those two things are equivalent, that isn't the purpose of an analogy.

The opposite seems true (regarding Go being over-fitted to Google problems).

It was designed for Google, but Google has not adopted it widely. Google is still heavily C++ and Java after all these years. The outside world loves it way more. Kubernetes isn't used internally at Google (except Cloud, which is not any different from any other cloud provider) though it's sponsored by Google. Bazel is probably in a similar boat.

Being designed to solve Google problems doesn't mean that it actually solves Google problems well, or that Google thinks it does.

I became introduced to Go through my startup and my experience was it a delight to work with in very small teams.

Palo Alto is in Santa Clara County whereas Menlo Park and East Palo Alto are in San Mateo. That might be how.

Agreed. This is very well written.

I discovered the joy of Go from dealing with JavaScript promises while writing an API service in Node. So many painful runtime errors uncaught or unlogged because promises don’t (or didn’t) require the catch callback.

I think inverting the programming perspective to default to sync instead of async is more productive for web services development, than perhaps for UI.