Hacker News Reader

This is nothing new. People were constantly introducing new languages back in the 1990s too. Of your preferred languages, Rust and Typescript are fairly new. They are among the success stories of this tower of Babel.

There's a constant churn of replacing and improving languages. Nobody is using Algol, Pascal or Smalltalk anymore, and even COBOL is losing ground. (Only Lisp and C seem to survive everything.) There's a constant process of learning and improving, that resulted in this latest generation.

And every language is good at something that no other language is good at. There are good reasons why some people prefer Perl, Python, Javascript or C for some tasks. Kotlin is rising in popularity because it's turning out to be the better Java that Groovy and Scala weren't.

Expecting everybody to use the same programming language for everything is like expecting a carpenter to choose a single tool to use for everything. And maybe a Swiss army knife really can do it all, but still not as well as a more dedicated tool.

> Kotlin is rising in popularity because it's turning out to be the better Java that Groovy and Scala weren't.

I'd say Kotlin is rising in popularity mainly because it's a Java alternative backed up by Google.

Backing by Google has helped, but I honestly think the two main reasons its succeeding are the same two reasons Typescript is succeeding: A "better" language that's "pragmmatic". What i mean is, they both provide the features people want (types, inference, less verbose than Java) and have quality out of the box tooling (because Jetbrains and vs-code). The moment I saw and tested either, I knew they would be a smashing success because they solved the problems people wanted solved, and "just worked".

The rise-and-fall adoption of Scala and Apache Groovy is because their whole rationale for existing was to be a better something. Groovy (2003) tried to be a better Beanshell (1998) by adding closures to it. Beanshell tried to be a better Java (1995) by adding dynamic typing to it. Scala (2003) tried to be a better Java by adding definable operators to it. But when something even better comes along, their rationale for existing disappears. They will try to catch up by adding features later (e.g. Groovy 2's inferred typing to compete with Scala, or its more recent macros to compete with Clojure) but by then the newer language has made a foothold, and it's too late.

> Scala (2003) tried to be a better Java by adding definable operators to it.

That's totally wrong. The reason d'etre of Scala is merging FP and OOP in a simple and elegant way. And actually there was no "fall" in rise-and-fall adoption of Scala. The adoption is growing.

I think it's not just that Groovy and Scala were temporarily a better Java that was eventually overtaken by the next even better Java, I think they were not sufficiently better. Better at some things, but with a cost not everybody wanted to pay. Groovy doesn't perform the way Java does, Scala is fast, but is a lot more complex and occasionally hard to read.

I haven't really tried Kotlin yet, but my impression is that it improves a lot on Java without any real downsides. It might not have all the improvements that Groovy and Scala offer, but it has the most important ones.

And it's a clean slate that leaves some of the poorer decisions in Java behind it.

> Groovy doesn't perform the way Java does, Scala is fast, but is a lot more complex

That's not quite how it seems for me. Groovy is faster than Scala in my hands (using CompileStatic) but its main challenge is complexity. It introduces a thousand quirks that have to be learned and then managed. There are some terrible legacy choices that can't be changed (eg: implicit coercion to Strings). I think this is behind the antipathy you see with people like Gradle users and Jenkins users that are incidentally exposed to it. But it applies also when you use it as a "replacement for Java". It has so many useful built in features but the price of that is all the implicit behavior of all of those need to be learned, along with actually learning Java really well, and with that along with less than perfect IDE support, and it's a steep steep curve.

Kotlin's main improvement on Java is its seamless integration with the most popular IDE on the JVM. Of course, it helps that IntelliJ and Kotlin are put out by the same company, but Jetbrains did emphasize when they first announced Kotlin that its integration with IntelliJ would be top priority. Groovy and Scala never had this improvement.

Yet, Scala has much better and broader IDE support than Kotlin these days. There is first-class support in IntelliJ IDEA, Eclipse and VS-Code, and with advent of Scala 3 the IDE story is going to be even better with full LSP support, so any IDE or editor could get accurate type-aware highlighting and autocomplete for virtually free.

Kotlin has good support only in IDEA and JetBrains said they wouldn't support other IDEs. They seem to make exactly the same mistake as Scala 2 did with supporting only one IDE initially (Eclipse).

If that's true, then Kotlin is successful despite its lesser IDE support.

Main reason for Kotlin uptake is Android. Kotlin is successful due to smaller footprint of its runtime lib and just-slightly-better Java philosophy, because it uses Java collections instead of bringing its own like Scala did. A big runtime library and problems caused by high method count hitting limits of Android runtime slowed down adoption of Scala on Android and allowed Kotlin to take that niche. Later the official support from Google reinforced its position.

> Kotlin's main improvement on Java is its seamless integration with the most popular IDE on the JVM.

Did Java not have seamless integration? I thought several IDEs (Eclipse, Netbeans and IntelliJ) were designed specifically around Java.

I think the rebranding of Intellij IDEA as Android Studio in 2013 was a good clue of where Google's long term plans were pointed.

It's not a rebranding. IntelliJ IDEA is still IntelliJ IDEA and is still owned by Jet Brains.

Android Studio is just Google's own version of it.

Without the "tower of babel" that exists you wouldn't get Rust or TypeScript, D, Swift or Julia.

Given that you mentioned them, I'm assuming you have some preference for them. So the world you'd live in would be a world in which your preferred languages wouldn't exist.

I guess that would be fine for some people, but not me or people like me. So there you have your answer.

You could get all the features of Rust by just taking features from an ML-family language and adding some low level memory manipulation capabilities, plus the theoretical work on lifetimes and all. It wouldn't "look like C" but it would be the same things.

You could get to any modern dynamic optionally typed language by just starting from Common Lisp, dropping the s-expressions and macros, and replacing default datatypes with something saner and easier to learn/teach.

There's a huuuuge bunch of intermediate steps that could've just been skipped. Maybe C isn't one of them, it was inevitable - of you wanted a portable higher assembler usable on 80s computers you could've only invented something like C. But Go, D, Julia etc. only repackaged existing knowledge...

> But Go, D, Julia etc. only repackaged existing knowledge...

Sure but you could also say that Google (the search engine) only repackages existing knowledge. Not much different from that famous HN comment [1] which says yould could use FTP & CVS instead of dropbox.

If we take Go as an example, sure code style guidelines were old news when Go came out, yet gofmt is still considered one of the best features of the language, because it removes bikeshedding and dictates the one true standard.

In other words, like in cooking, it's not so much about the ingredients but how you package them.

--

[1] https://news.ycombinator.com/item?id=9224

I don't know if any language can exist solely as repackaged knowledge. Sure, a language can very well start that way, but you now have n features that need to be integrated with each other in a still unknown way, which brings new challenges and new knowledge. And no language is static and no technique is completely generic, so any complex software will have issues that will need custom solutions that will again lead to the creation of new knowledge.

For example Julia didn't invent multiple dispatch, but it's intention to use it to high performance numeric computing meant different constraints from Dylan or CL, which led to the creation of it's own unique paradigm around type specialization and promotion to make it work. But eventually people had troubles with extremely complex dispatch rules, so, thanks to the language also having repackaged the Lisp knowledge in itself, the language designers were able to create a unique macro to make dispatch rules turing complete (generated functions). And then people realized it could be used for source to source manipulation, for example in the state of the art ML project Zygote.

You'll certainly find many examples like that in any minimally ambitious language.

"There's a huuuuge bunch of intermediate steps that could've just been skipped."

Except they couldn't have just been skipped. In retrospect? Maybe. But I suspect we'll see another several thousand languages in the next 20-30 years, most of which will be very, very much like what came before, and a very few that ultimately matter. I don't think there's any way around that except in hindsight.

Okay, let's go to 1989 and apply this mentality.

Three languages to suffice all needs:

* Low-level systems language: C.

* Highly expressive, high-performance industrial language: C++.

* Interactive interpreted language for doing easy casual things: Basic! Everybody knows Basic already.

Halt the language research, stop trying to develop Python, Lua, Java, OCaml, Haskell, Smalltalk, etc. Who ever needs them?

In plain words: diversity is how evolution works. You cannot build a perfect thing from the start (no, not even Lisp, apparently). You have to try and reality-check. Standardizing on One True Tech is how you end up with reams of despicable legacy code 15 years later, and with no way out.

Good point, but Smalltalk was basically fully baked in 1980. That's why they called it Smalltalk-80.

The languages are quite different though and there are good reasons for using different ones in different places:

1. Kotlin is basically modern Java, and is therefore an obvious choice for Android which still runs everything in a JVM.

2. Go was basically designed to run network services and it is very good at it. The standard library is excellent (probably the best of any language) and concurrency is pretty easy too.

3. The Flutter team have published their reasoning for using Dart. Can't say I fully agree with all of them but it is a reasonably nice language (way better than Javascript anyway - although I know that doesn't take much) and developing with it is really pleasant.

I don't know why TF chose Swift though. It looks like a nice enough language though.

There are definitely significant differences between all of those languages. It's not like they're using a mixture of Javascript, Typescript, Flow and Dart. That would be silly.

I suspect that TF "chose" Swift because Chris Lattner (the creator of Swift) joined Google, and he managed to convince people that it would be a good idea.

To what extend, is Swift being used for ML or DL by Google or others? Is it a new TensorFlow core? Or just just another binding?

It's an alternative interface for Tensorflow (the existing one is Python). The core of Tensorflow is still written in C++.

I kind of get your point.

But I have to say after spending a fair amount of time writing C, C++, and Java, I found go quite refreshing. The simplicity of syntax, design, and implementation of go does reward using it for what it's good at.

So simple in fact that I'd happily pick up another simple language or two for things that Go is not good at.

I'd much rather have a few somewhat narrow language like go, instead of the ugly mess that is C++. Can anyone normal serious C++ programmer understand all of C++?

Yep. Swift is open-source and pretty decent. Google should clean house and go with the language that would attract the most developers.

They should invest into making it pleasant to use in Linux and Windows too if they want adoption...

ML devs (using mostly Linux) will not bother to build a useful rich ecosystem of general purpose libraries. And amongst the other devs, Windows matters a lot, macOS is a small and shrinking niche outside US.

Swift doesn't work natively on Windows which is a massive downer for many people.

It doesn't yet, but good progress has been made recently on that front: https://forums.swift.org/t/swift-windows/22458

Cygwin could be an option.

1. Why would swift attract most developers?? It's a fairly small language outside the iOS bubble.

2. Google has invested tons of money in 3 different languages and each works _extremely_ well in it's intended domain.

3. Even as open source, remember Apple has a history of crippling software on competing platforms.

The specialized languages are a pain, but a single language that tries to be everything to everyone tends to be more of a pain. That's because it can't specialize, it has to adopt the lowest common denominator approach. As a result it's unlikely to be the best in any given area (sometimes it happens, but rare in my experience).

Where this hurts the most is in hiring. To get a job with Google you'll either learn one of these really well and so only be able to apply to one area of Google, or you'll learn several of them but not go in depth as much in the same amount of time and be able to apply to many different areas of Google.

Your idea of a limited language ecosystem (a languages for each of system, web, and metal-to-abstraction) is a good idea, but I think it still invokes the LCD problem. Though nowhere near as much. It would not surprise me that much if we hit the extreme of specialization, with a specialized language for each slot of the {mobile, server, desktop UI, IoT} x {each of the seven layers of the OSI stack}. As I wrote that I was thinking you could create Karnaugh map like depictions of languages to show what areas they cover.

I think a very varied programming language ecosystem is a good thing, and we're never going to get a one size fits all language, but there's a balance needed. The jury is still out and I'll have to see if it turns out well.

> "tower of babel"

The hallmark of a fragmented corporation, with internal competition between divisions.

Which, if you're the size of Google, is probably the way you want it. At least then great new ideas have a chance to survive when they threaten the current product line.

I agree to a certain extent, ( And the list is missing Elixir / Erlang )

But if we look at it from a very high level, I see this sort of happening already because Kotlin and Swift are very similar. They have both taken all of their ancestors's good idea and repackaged it within their own constrain. ( JVM and Objective-C ).

And combatively speaking, Rust is new. It hasn't been tested by millions of developers and production usage. Where they may find edge case in its concept and design, before we reach a conscious to replace C or C++, if that is even needed.

CoffeScript died ( in terms of Development, not usage ), because JS evolved, someday TypeScript may died too, as it itself might become the future of JS.

So over time these PL and idea converge, and consolidate. And through Natural evolution we will reach that point you described, with few languages that all look similar. And I would not be surprised if 5 - 7 years down the road C# ( Microsoft ) , Kotlin ( Google ) , Swift ( Apple ) all looked similar.

As to why it shouldn't be just one languages, well I doubt M$, Google, Apple will ever play along well with each other.

Programming languages are products.

Once upon a time, the OS of choice would dictate which languages were tier 1.

Nowadays the platform has taken up that role.

> ...great, Kotlin for Android, Dart for Flutter, on the ML side they're starting to adopt Swift, for networking infra code Go.

Don't forget HTML+JS+CSS for websites and PWAs. And given that web technologies work across all platforms, perhaps that's the area for developers to keep focusing on.

> And given that web technologies work across all platforms...

This is a myth. Web technology is more "Write Once, Debug Everywhere(tm)" than Java ever was. The real value is in deployment, bypassing all the platform bullshit. It's still a severely limited platform and will probably remain so, because Apple has no interest in giving up its walled garden.

After experiencing Android development with Kotlin, I will choose Kotlin again by default. Admittedly, my experience with the most recent version of Java is not there, but Kotlin has some things I never found in Java. It statically checks for possible null pointer errors, and you can define free functions (without a class definition). Another nice thing is being able to declare constructor parameters as fields at once, and also automatic generation of getters / setters with data classes. This saves a ton of boilerplate. Maybe Java has some or all of these things now, but last time I used it, it didn't. I don't see it as a tower of Babel, but you have to keep on learning.

If you ever hop back into the realm of Java, take a look at Project Lombok [1]. It adds a list of helpful annotations for those sort of features.

—

[1] https://projectlombok.org

It's only from a very high-level view that these languages might look all the same. If you look at how the languages actually evolved, there are crucial differences.

Swift basically exists due to Apple's need for Objective C compatibility. What other language would serve that need? Similarly, Kotlin was easy to adopt for Android due to Java compatibility. Rust is designed to interoperate well with C++, which is useful within Firefox. Go was designed for fast compilation and easier library evolution for server-side code in a Google-scale monorepo. Dart was designed as a browser scripting language (though this didn't work out).

There was nobody in a position to prevent all this evolution from happening.

> Rust is designed to interoperate well with C++, which is useful within Firefox.

Mild nitpick, but from my understanding Rust interoperates well with C but is quite a pain to interoperate with C++. At least calling C++ libraries from Rust is painful, the other way around can be easy in the same way that calling C code is easy from C++.

This debate can get out of hand, but the Android eco system and its developers will benefit immensely if Swift is adopted instead of Kotlin - it enables devs to share code.

thinking about nim(rod) I'm quite happy that there are still ppl trying out stuff.