4 ms·
Ok but it isn't true that there are no brown languages that are loved. So the interesting exercise is to try to figure out which green languages will remain lov
by sanderjd 6y ago
Ok but it isn't true that there are no brown languages that are loved. So the interesting exercise is to try to figure out which green languages will remain loved after they turn brown! Obviously this is hard to guess at.
My guesses from the green list: I think Kotlin and TypeScript will remain loved; they solve a real pain point in a simple and well curated way. I think Scala will be dreaded (actually I would already put Scala in the brown category). I think Haskell will remain both loved and dreaded; I think it's a bit different than the rest, because I don't think people mostly dread it because of maintaining old systems, I think whether or not it clicks is just very personal (I'm personally in the "dread" camp on it, though I appreciate many of its ideas). I don't have enough experience with Dart or Julia to make a guess.
The most interesting questions are Go and Rust. My intuition is that I think Go will be like Ruby: quite nice to start with, but increasingly unwieldy as projects get bigger and bigger. I do find it pleasant to hack on small Go files, but would dread joining a project with millions of lines of code. Rust could be dreaded as the C++ of the future, known for big unwieldy difficult to maintain codebases. Or it could be loved as the much better C++ of the future, known for making big unwieldy difficult to maintain codebases more tenable and enjoyable to work with. I'm not sure!
- H1Supreme 6y ago> increasingly unwieldy as projects get bigger and bigger. This applies to any project in any language. How would it be worse in Go versus Kotlin or Typescript?
- The_rationalist 6y agoThere are many features in such languages that allow to reduce cognitive overhead, such as null safety.
- sanderjd 6y agoYep, as the other commenter said, languages scale differently because of the entire suite of different and interacting features. I know it's cliche to say, but I still believe it's true, that Go suffers from lacking generics, particularly as a project grows. I see big projects with lots of `interface{}` usage to work around this, and at that point the type system is essentially equivalent to Python's, which in my view is harder to maintain at scale. This seems a lot more common in big Go projects than use of Object in big Java projects, for instance, and I think it's a smell. I also think nil-based error handling is harder to maintain than languages with no nulls, or strongly discouraged nulls (but most languages have this problem). I don't have a good sense for how well the concurrency functionality in Go scales, but I get the sense that it's pretty good, and superior to most other languages, including the other ones in this thread.
- bcrosby95 6y agoWhat problem does Kotlin solve? It's basically a "better Java" - the problem being Java is becoming a "better Java" too. I feel like eventually Kotlin will collapse under its own weight as it continually tries to outpace Java and takes mis-steps. Sorta similar to how Scala did - many looked at it as a "better Java" during Java's period of stagnation.
- eweise 6y agoI'm cautiously optimistic that Scala 3 will more towards most loved vs hated.
- nytgop77 6y agoIt solves nightmare of groovy (gradle.build scripts). Kotlin makes gradle bearable. https://quickbirdstudios.com/blog/gradle-kotlin-buildsrc-plugin-android/ https://quickbirdstudios.com/blog/gradle-kotlin-buildsrc-plu...
- sanderjd 6y agoI think it's harder to become better backwards compatibly, and that for that reason it is unlikely java will ever catch up to some of the most compelling good (in my opinion) decisions Kotlin made. But your point is a good one and you may have convinced me that my guess is wrong about Kotlin for this reason.
- obviouslynotme 6y agoPeople dread Haskell because Hello World uses monads.