On inventing new wheels…
-
Every programmer dreamed of writing their own language since the dawn of time, but lately companies seem to have gotten infected and started churning them like mad, and due to the resources thrown at them, are even moderately successful in getting them used. There is Go, and Rust, and Swift, and Kotlin, and Dart, and TypeScript… But designing a good language, with actual benefit at least for some class of uses, is really hard. So what are the actual, practical benefits of:
- Go? It looks like Google engineers grew tired of the Java verbosity and memory inefficiency. It does seem to have decent whipuptitude, though I am not sure it has any specific killer features.
- Rust? This is the only one where the benefit is clear—static analysis to avoid memory error for when you need the performance and control or manual resource management. That the rules also prevent many threading issues is a nice benefit.
- Kotlin? I understand it basically as newer-Java-features-backported-to-what-Android-can-digest, with a bit of syntactic sugar on top.
- TypeScript? Ok, static typing does improve the manipulexity somewhat. I haven't looked whether the execution is worth it though.
- Swift? Dart? I haven't looked at them yet…
So I wanted to ask, do you know any killer features that make these new languages actually worth learning and pushing into production? Do you know any other new(ish; it takes 10 years to make a good software, so last 10–15 years) that have some killer features?
-
@Bulb said in On inventing new wheels…:
TypeScript? Ok, static typing does improve the manipulexity somewhat. I haven't looked whether the execution is worth it though.
From my experience, it helps the IDE know what's going on so it can autocomplete stuff, find references (ish), and yell at you when you try to put a string into a number or whatever.
-
@Bulb said in On inventing new wheels…:
Every programmer dreamed of writing their own language since the dawn of time, but lately companies seem to have gotten infected and started churning them like mad
Lately? From what I've heard, in the 90s every IT company big and small has committed at least two different DSLs for use in their tools.
-
@Bulb said in On inventing new wheels…:
TypeScript? Ok, static typing does improve the manipulexity somewhat. I haven't looked whether the execution is worth it though.
I've had to do a medium-sized project in JavaScript for college class. This was my first real experience with JS. Half the time I spent on searching far and wide all over internet what kinds of values a given function in a 3rd party library returns. Something I could do in half a second if I had type definitions. I did end up digging through sources of both node-mysql2 and Express.
It's somewhat better with Python, but only because Numpy is so well documented and I haven't had to use anything else yet.
-
@Gąska Yeah, but I found TypeScript rather complicated to use - it's basically a second language plonked on top of Javascript because the Typings files can get really complex.
I'd rather use a language which has been built with Strong Types from the start which then could be compiled down to Javascript or WASM if need be. I mean if you're using Typescript you'll involve a compiler anyway so...
-
@Gąska said in On inventing new wheels…:
DSLs
Yeah, DSLs were always big. But at least those didn't have much ambitions to be used beyond the project. And fortunately lately many learned to just slap Groovy or some such in there and call it a day.
-
@Rhywden the idea is that TypeScript can be incrementally added to pure JavaScript code, one function at a time, and programmers have immediate benefits without going all the way with their entire codebase. It's quite literally plonked on top of Javascript.
Sure, for a new project, a language designed with static type system right from the start is better. Theoretically, depending on ecosystem integration. I wasn't really recommending TS, I have no direct experience with it; I was just saying that lack of types is a really, really, really big problem, and that anything with types is better than JavaScript almost by definition.
-
@Rhywden said in On inventing new wheels…:
I'd rather use a language which has been built with Strong Types from the start which then could be compiled down to Javascript or WASM if need be.
There is a couple of them now. Which brings us back to the original question—do they have any killer features to make them worth picking up?
TypeScript was created to be easy to integrate with the existing body of
JavaECMAScript crap. Similarly to Scala and Kotlin being designed to integrate with the existing body of Java crap. I am not sure how good the other languages are for that purpose.
-
@Bulb said in On inventing new wheels…:
@Rhywden said in On inventing new wheels…:
I'd rather use a language which has been built with Strong Types from the start which then could be compiled down to Javascript or WASM if need be.
There is a couple of them now. Which brings us back to the original question—do they have any killer features to make them worth picking up?
Compared to JavaScript? Yes - types.
Compared to TypeScript? Well, you don't have to deal with all the other JS fuckery, that's definitely a plus. But I imagine integrating with existing frontend ecosystem - not just running projects, but also libraries and frameworks like React - could be a pain. Although I have no direct experience with WASM or Emscripten, so I allow the possibility I might be wrong here (and would actually love to be proven wrong here! A sane language for throat development would be great.)
-
-
@Gąska said in On inventing new wheels…:
not just running projects, but also libraries and frameworks like React - could be a pain
The standard browser APIs are bound (there even exist suitable declarations for the glue to be mostly generated), and at least Rust made good progress in exporting and importing ECMAScript interfaces from/to WASM. Something like React does not seem to be directly reusable, but it is not actually that complex and corresponding libraries can be written.
Rust is probably furthest in WASM support at this time, because C++ is a bit of a lost cause for front-end and most other languages are blocked on the garbage collector integration.
@Gąska said in On inventing new wheels…:
A sane language for throat development would be great.
That seems to be what Google is trying to do with Dart (and the Flutter framework), but I didn't get a
to looking at it at all yet—I was hoping to find somebody here who already has some experience to share.I've also encountered some Elm fans. That's another new language that is partially domain-specific in that it is tied to the DOM event/update/rendering loop. And the yew framework for Rust looks promising. There might be something for Go, but I am not a big fan of Go, so I didn't look.
-
@dkf said in On inventing new wheels…:
@Gąska said in On inventing new wheels…:
Numpy is so well documented
*nervous twitches*
I'm sure it was sarcasm.
-
@Bulb said in On inventing new wheels…:
Dart […] but I didn't get a
to looking at it at all yetOk, so I gave it a quick look. It does not seem to bring much new, really, just a pile of features collected from Java, C# and JavaScript, in a slightly different packaging, which makes
_Properly._Written._code(_look._ugly()). It even still makes the biggest mistake of Java:null, and has plenty of ECMAScript-derived idiosyncrasies for ECMAScript compatidebility—though it does not seem to be particularly interoperable with it, just compilable to it.Generally looks a lot like serious case of NIH syndrome. Actually I'd even say NIBM, because they already have Go that they already managed to make somewhat popular to which they could have added the features to cover the use-cases, and writing Go compiler to AsmJS (while the native ones already exist) still sounds like much less work than writing a complete new multi-target compiler, and they would have all the libraries that already exist.
-
@Bulb I'm confused as to why
nullis a mistake?
-
@dkf said in On inventing new wheels…:
@Gąska said in On inventing new wheels…:
Numpy is so well documented
*nervous twitches*
In comparison.
-
@Rhywden said in On inventing new wheels…:
@Bulb I'm confused as to why
nullis a mistake?From the creator of null himself:
Null References: The Billion Dollar Mistake
Tony Hoare introduced Null references in ALGOL W back in 1965 "simply because it was so easy to implement", says Mr. Hoare. He talks about that decision considering it "my billion-dollar mistake".
-
@Gąska said in On inventing new wheels…:
@Rhywden said in On inventing new wheels…:
@Bulb I'm confused as to why
nullis a mistake?From the creator of null himself:
Null References: The Billion Dollar Mistake
Tony Hoare introduced Null references in ALGOL W back in 1965 "simply because it was so easy to implement", says Mr. Hoare. He talks about that decision considering it "my billion-dollar mistake".
Yup, that's precisely what I was referring to.
@Rhywden said in On inventing new wheels…:
@Bulb I'm confused as to why
nullis a mistake?Because if
nullis a member of every type, always, then you have to put checks for it all over the place and the compiler can't help you much even though for most variables it is a bug to ever be null. Some languages have already learned to only allownullin places explicitly marked as nullable and then tell you to handle null when going from the nullable case to the non-nullable case (and methods can only be called on non-null). It reduces the whipuptitude a little, but leads to significantly more robust code as it starts to grow.
-
@Bulb said in On inventing new wheels…:
Kotlin? I understand it basically as newer-Java-features-backported-to-what-Android-can-digest, with a bit of syntactic sugar on top.
One of its features is that all native Kotlin variables must have a value unless they're explicitly declared as nullable.
Disclaimer: I haven't actually used it because I'm working 100% .NET these days, but the above was told in the presentation of one of the Jetbrains guys.
-
@JBert said in On inventing new wheels…:
@Bulb said in On inventing new wheels…:
Kotlin? I understand it basically as newer-Java-features-backported-to-what-Android-can-digest, with a bit of syntactic sugar on top.
One of its "features" is that all native Kotlin variables must have a value unless they're explicitly declared as nullable.
Why scare quotes?
-
@JBert It's almost like you missed all the discussion above.
-
@Bulb said in On inventing new wheels…:
@JBert It's almost like you missed all the discussion above.
And this is abnormal or otherwise noteworthy.... why?
-
For kotlin, the features you s a denser and more expressive language than Java, it also has the nullability feature which I like, and it's usable to create multi platform libraries where all your logic is in one language, with target specific glue code outside of the logic. It's for instance useful for only creating data structures, validation and business rules code once for both backend and several different clients.
And "POJOs" are immensely less eye cancer in kotlin than Java.
It's also got a bunch of neat features shamelessly stolen from other languages.
But it's a nice language to work with, and I've done so once or twice. At my current gig I'm trying to get it into the accepted languages so that I can use the multi platform library stuff.
-
@Gąska said in On inventing new wheels…:
@JBert said in On inventing new wheels…:
@Bulb said in On inventing new wheels…:
Kotlin? I understand it basically as newer-Java-features-backported-to-what-Android-can-digest, with a bit of syntactic sugar on top.
One of its "features" is that all native Kotlin variables must have a value unless they're explicitly declared as nullable.
Why scare quotes?
Huh, now that you mention it: I have no idea. I think I started with
"biggest features"and then edited outbiggest.What I meant is that it seems handy but not something for which you would suddenly port your entire codebase from Java (is there actually ever a good reason to do such a Big Bang conversion?).
@Bulb said in On inventing new wheels…:
@JBert It's almost like you missed all the discussion above.
There were almost no more mentions about Kotlin since you post, and I'm just mentioning its default non-nullability.
-
@JBert said in On inventing new wheels…:
default non-nullability
Which is exactly the point of that discussion. I.e. the “scare quotes” are not really appropriate—it is probably indeed it's best feature (and I didn't realize it had it as I didn't look at that one in much detain either).
-
@Bulb said in On inventing new wheels…:
So what are the actual, practical benefits of:
- Swift?
It’s [not [Objective-[C]]]?
-
@JBert said in On inventing new wheels…:
is there actually ever a good reason to do such a Big Bang conversion?
In general, only when you've hit a truly major brick wall. We've rewritten a lot of our code from Python into Java precisely because we hit a critical performance problem during data transfer because Python's got utterly miserable threading support, whereas Java doesn't. It's proved to be extremely difficult to do and exposed all sorts of weird problems along the way (including where the increased rate of network traffic showed that the remote side's OS had critical bugs that would crash the whole system in an un-debuggable state, which was “nice”) but the ten times speed up is rather strongly worth it.
Most code never hits that sort of wall.
-
-
@JBert said in On inventing new wheels…:
What I meant is that it seems handy but not something for which you would suddenly port your entire codebase from Java (is there actually ever a good reason to do such a Big Bang conversion?).
That's the fun of Kotlin. Unlike Scala which does its own thing and just happens to be on the JVM, Kotlin prioritizes compatibility with Java, in both directions. You could start writing Kotlin code right now in a Java project and it'd work out just fine.
-
@Bulb said in On inventing new wheels…:
Swift?
C# is what I wish Java was and Swift is what I wish C# was. A C#-style
class/structtype system, with Rust's explicit equatability for types. Kotlin-style properties (i.e. "what's a field?") and nullability. Rust'sif let, except used everywhere and making for some really expressive pattern matching, along with its enum structure types. There's stuff I didn't know I wanted, like interfaces requiring constructors, or extension methods being used to implement interfaces. Also stuff I definitely did want but no language before it had, like defining assignment via a string or array literal without implicit conversions, or a way to have a class that the library can extend but end users can't without using private constructors. .NET 5 will reportedly have Swift support which makes me really happy.
-
-
@Bulb said in On inventing new wheels…:
Rust? This is the only one where the benefit is clear—static analysis to avoid memory error for when you need the performance and control or manual resource management. That the rules also prevent many threading issues is a nice benefit.
I'd say "suitable for embedded development and not C" is also a killer feature.
