Not to be the perpetual Luddite, but I hate how much programming languages change. I don’t particularly like go as a language (good board game though), but the minimal changes over time starts to feel really correct.
in JS (and years before that, PHP), one example was object-oriented programming / classes, except in both JS and PHP it was never implemented fully, with JS not even having access modifiers for a long time. JS didn't need classes and the implementation is lacking, but someone decided it should be added.
Likewise, Java had functional programming bolted on; they never extended the base List types with functional modifiers, so now you have to transform or wrap your List in a Stream to make it work with Java's attempts at functional programming. Personally, I think if you want to do FP or FP-style coding on the JVM, you should rewrite things in Scala. You can write Scala and Java side-by-side.
Same with JS, you want JS but with types? You can have Typescript. I wish they did the same with JS-with-classes, just write a new language that compiles to JS instead of bolt classes onto the JS standard.
But I greatly dislike multi-paradigm programming languages. Mostly because I've worked with other programmers.
Borrowing features (idioms) from other languages is great. Pattern matching is nice. For Java, I'm looking forward to (interpolated) string templates and implicit classes. Destructuring would be nice too.
--
But for the love of Larry, where are intrinsic regex expressions?
Path expressions?
Most of our work is data processing.
Input -> munging -> output.
Meaning cutting and pasting strings.
So I mostly want new features related to string and data processing.
--
The evergreen fetish (kink) with arcana like type systems, monads, and metaprogramming is just so besides the point. That's what Lambda the Ultimate and HN are for.
For "commercial" languages, just give me tools for work.
Fussing with novel languages is for my hobby projects.
(I agree with your overall point BTW.)
I just checked; the MDN docs refer to them as "regular expression literals".
Jeremy tried https://arcturo.github.io/library/coffeescript/03_classes.ht...
I think the classes were a good thing. Better would have been to change the OO model entirely, but if you're going to have one and can't change it, nice to at least have some sugar to make it usable. IDK if it's better elsewhere, but prototypal OO was pretty clearly a miss-step for Javascript, and sugar to make the OO system usable and less-obtuse (while making it easier to ignore the parts that should basically never be used, which parts amount to all the distinctive things about prototypal OO) is a decent move.
Wow, relevant username for this take, as you'd end up with an eldritch creature as soon as people tried to bolt these DSLs together into their opinionated bags of features, and a meta-language landscape that resembles the already fragmented frontend landscape of today
I'd also argue that the majority of these changes are to the standard library (new methods on String, Array, RegExp, etc). Not really core language changes. I don't know how often the go libs update but surely faster than the language spec?
What?
In fact this is how TypeScript is implemented.
I know the quote you're referring to but you're stretching a mile to get there.
In the case of TypeScript, we have the base JavaScript, template literals, and the type system all playing this game in the same file. Three systems trying to out feature each other. Tagged template literals, template literal types, etc.
I’m not entirely sure this is a good thing. But it’s certainly convenient in some instances.
I used Go wrong for years. Once I stopped doing dumb stuff with it (especially with the type system), it got a lot more pleasant. I don’t think I’d design it the same way, but I’m quite a bit happier using it now.
It’s kind of like using a hammer to drive a screw. The problem isn’t the screw or the hammer. Go seems to be a hammer-screw situation for a lot of people, but there really is a happy path.
Not saying this because I think you’re unaware — mostly thinking out loud because I used to feel like Go needed new features and your comment reminded me of this. I also like the relative stability of Go now, though. It has a great foundational toolset and good design overall, so to its credit, it hasn’t really needed to change so much. I only thought it did because I used it wrong.