569 karma · joined November 28, 2022
The go devs decided against this since they didn't want to build a highly optimizing (read: slow) compiler, but that is missing the point of developer ergonomics.
Hardware (see also, Google's TPUs and their performance vs. energy cost) is one reason why I'm fairly bullish on Google.
It just didn't seem feasible, for a lot of reasons.
Of course, how feasible it sounded will depend on your interpretation of "superset". I wonder what was the straw that broke the camel's back.
For example, the async problem still exists and still has absolutely no viable path forward, or even MVP approach.
And that's not even getting into the problem that it's a fairly controversial feature, since people are worried about terrible, hard to track specialisation trees. (See, inheritance.)
And fwiw, I heard of two tragic cases of children dying, which sounds remarkably low to me so far. If this were truly indiscriminate, this number would be significantly higher and we would've heard of it by now.
Children (and potentially health workers, as opposed to men of fighting age) are much more likely to die of such an explosion than men of fighting age. In other words, children will be significantly overrepresented here.
As far as we know this was a supply-chain attack specifically on military pagers actively used by Hezbollah, and (right now) it looks like most injured are in fact Hezbollah members (which makes sense, since no one else has any reason to carry such a pager). (With some sad and unfortunate exceptions.)
Python's `A | B` is a union operation, but in Rust a sum type is always a disjoint union. In Python, if `A = B = None`, then `A | B` has one possible instance.
In Rust, this sum type has two possible instances. This might not sound like a big deal, but the semantics are quite different.
What did you actually gain from this, outside of more work?
> As async is already used as an identifier in C#, the team decided to use async2 as a codename for the experiment. If that thing ever makes it into the runtime, it will be called async - so it will be a replacement for the current async implementation.
It's probably simple, but the control flow just felt convoluted.
It just doesn't seem worth it to define a whole new thing just to abstract over a format() function call. The laziness might be interesting, but I feel like "lazy strings" might be all that's needed here. Laziness and validation (or custom string formatting logic) are separate concerns and should be separated.
I think the focus here is on "selections", as opposed to just "cursors".
So for example, you can select all occurrences of X (say, usage of some global variable), then say "for each of these selections, select the whole function", and then say "select the name of the function".
And bam, this is a (somewhat artificial and forced example), but you assembled a list of all functions with a specific property in a few button presses without ever leaving your editor. This is very close to stuff I do all the time in Helix. This is a godsend when it comes to manipulating (for example) a huge array of JSON data.
Maybe this is all obvious to you, but this seems like the kind of thing that probably still feels like black magic to a lot of programmers, and which certainly hasn't reached all editors yet (most are not focusing on selection editing as a first-class usecase).
Where's all the fun stuff? Debugger features are neat, but outside of this these features just seem tiny and cute and not too exciting.
Even stronger support for structured Treesitter-based editing? (See eg. Helix), proper multicursor support (Helix), both already seem like black magic to me compared to what came before.
I think it's probably intended to be that, yes.