[klibertp]

> see an interesting language concept, but it's not entirely here how that relates to the initial claim.

I didn't see any concept which wouldn't be practiced in PL design for decades. Yeah, they may not be widely known, but suggesting that "structural, nominal, and union" types are anywhere near any kind of "breakthrough" is just too much. If anything, the language seems conservative in its design rather than novel.

EDIT: actually, this looks like a much better link, in that there's at least some meat to chew on: https://github.com/microsoft/BosqueLanguage/blob/master/docs...

[zenexer]

Right, I don't see the justification for "breakthrough" on that particular page. It's interesting in that it's attempting to bring more performance to the JS world using old tricks, but from that page alone, I wouldn't call it breakthrough. I'd need to see more concrete justification for that term. It's possible that the compiler itself is truly groundbreaking, but that isn't really addressed in the readme.

[klibertp]

I actually went through the language doc, which describes the language in more detail (there are still some WIPs and TODOs). I was able to name at least one language which would be considered "prior art" for every one of the features detailed there. A good deal of languages also come close to supporting all of them in one package, and languages that offer most of the features are a dime a dozen.

There are a few mentions here and there which do look interesting, but whatever the "breakthrough" turns out to be - and maybe there really is one - it won't be in programming language design for sure.

[nwienert]

This can almost be said for many languages, even the popular ones like Rust which didn’t event most of the things it does.

Who cares? It’s all about how they put it all together. Plus some of the IR stuff is interesting.

Basque strikes me as a better attempt at a new Typescript than Reason. I really like that they are adding things like check, assert, validate into the language itself. I mean it just looks far better than TS in every way, especially once it starts to optimize all the language information it has. And it’s totally fine it’s not new. What matters more is that it puts them all together in the right way, moves at a good pace, gains traction.

I’m curious the interop story. Performance stats. DX. Look at TS vs Flow. I tried both numerous times and it was just so obvious TS was leagues ahead - far easier to set up, work with existing code, nicer errors (early on), and they just relentlessly improved it while Flow was crickets.

I don’t care so much about it being a breakthrough (though I can see how it’s basically as big a breakthrough as Rust, if it’s done right), but that it becomes viable. Sure, Reason or any of the other hundred I’ve seen come and go over the last few years would be cool too, but for whatever reason they aren’t “catching” fully. Reasons interop is finicky, the language is very verbose, and it’s just been way too quiet (where are the big releases?), but they got most of the rest right. This seems to get as much if not more right, so we’ll see if MS pushes it like they do TS, I hope so!

[klibertp]

> I really like that they are adding things like check, assert, validate into the language itself.

I'm not sure. Contracts are supported in some other languages as a library feature; recent examples I encountered were Elixir, Scala, Clojure, and Haxe; there's also, of course, Racket, but there it's hard to say where the library ends, and language begins... Eiffel, Cobra, Pyret have contracts as a language feature - it may be easier to support it that way instead of first making the language expressive enough and then writing that library.

> What matters more is that it puts them all together in the right way, moves at a good pace, gains traction.

No, out of these only the last one matters: there is no "good" pace (you're either moving too fast or too slow), and there is no "right" way to design a language. The only thing that matters for a language is to gain traction - otherwise, it dies - and that seems to be almost entirely unrelated to the technical features of the language. Luck (e.g., C, Python, PHP) and money (e.g., Java, C#, Go) seem to play a much greater role in making a language successful, along with vendor lock-in (e.g., Objective C, Java, C#).

The lag between an innovative feature conception and its implementation (in the mainstream language(s)) seems to be 10-20 years on average, but it can sometimes take 50+ years while a feature is repeatedly discovered and forgotten in 10-20 years cycle. For example, there are optional static type systems (for otherwise dynamic languages) in languages from the '80s (ie. Common Lisp) and '90s (ie. Dylan), and the more formal gradual typing is IIRC from 2001 (by J. Siek). TypeScript, Flow, Python's mypy, and similar solutions are a mainstream-ish emanation of these ideas - it them took some 15 years to materialize and a few more to appear on the "working programmer" radar. This is a very common pattern: basically, if you want to know how programming will look like in a decade, you can simply look at the experimental features and ideas from 10+ years ago.

[nwienert]

So basically I pointed out a novel feature that is great and you refuted it with.. that it exists a library? Well, yea. That’s not really a point.

Having it built into the language is the feature - it means compile time optimization and much better vertical integration for errors, analysis.

Also there is absolutely a good pace, you admitted it! I didn’t say “fast” note, hah.

Finally, yes. I know all the trends, etc. Not sure what your point is, it doesn’t refute anything I said.