i_s

I think there is some truth to this. But it may just be that the threshold for viable open-source collaborative projects increased by an order of magnitude or two. E.g., today if you make a cool datetime library, nobody will care, they can recreate the parts they need in 5 minutes. If you make something much harder to reproduce, then maybe they will. So I just file this under “you need to be more ambitious.”

Maybe we have to subsidize zoomers until we can figure this out.

If I type the name of an enum, then `.`, (and for my settings explicitly request autocomplete suggestions from VsCode), I either don't get anything, or I get a list of 50+ identifiers that have nothing to do with the enum. There seem to be a lot of cases like that where there is a very obvious context, but the suggestions are completely detached from that context. Stuff that works for any mainstream language like Java or TypeScript in just about every IDE or editor with a plugin.

KSON looks interesting. Where I work we did a metadata type project in Pkl recently, which is somewhat similar. Unfortunately, developments on the tooling front for Pkl have taken an extremely very long time. Not sure the the tooling/LSPs are anywhere close to what the language offers yet.

I like the language embedding feature in KSON - we would use that. Have you thought about having functions and variables? That is something you get in Pkl and Dhall which are useful.

Couldn't you just use static classes? I don't see how that would be a factor at all, seems like a very superficial reason that would be easy to work around.

Yea, I came here to say the same thing. Anders' reasons for not going with C# all seem either dubious or superficial and easily worked around.

First he mentions the no classes thing. It is hard to see how that would matter even for automated porting, because like you said, he could just use static classes, and even do a static using statement on the calling side.

Another one of his reasons was that Go was good at processing complex graphs, but it is hard to imagine how Go would be better at that than C#. What language feature that Go has, but C# does not supports that? I don't think anyone will be able to demonstrate one. This distinction makes sense for Go vs Rust, but not for Go vs C#.

As for the platform / AOT argument, I don't know as much about that, but I thought it was supposed to be possible now. If it isn't, it seems like it would be better for Microsoft to beef that up than to allow a vote of no confidence to be cast like this.

I've read this a few times over the years and I think the argument is sound. But I wonder if it is sound in the same way this statement is:

"It is better to go picking blueberries before they are fully ripe, that way you won't have much competition."

I say higher earners and you think I'm just talking about billionaires? Deranged.

I'm just people at higher than the 50th percentile. Say 75th percentile, which probably includes a lot of people from HN.

Norwegians are rich if you look at the average, but if you compare higher earners there vs the U.S. I would say they are actually poor. For example, take an above average software developer in the US and compare them to one in Norway - you will see a massive difference, especially in disposable income.

I'm not sure the use of 'accidentally' was sincere. But I like this choice of words in your post in your first version:

> unmercenary assumptions

Not if he does the type of job hopping typical in silicon valley. There are plenty of programmers who only stay at a job ~2 years, and never have to maintain a program over a long period. You could imagine such a person saying 'this worked well at my last job' and just keep introducing that kind of pattern to new companies, eventually with '20 years of experience'.