6 ms·

It's amazing how many people in this thread justify their own language choices by making negative, sweeping statements about another language (Scala in this cas

It's amazing how many people in this thread justify their own language choices by making negative, sweeping statements about another language (Scala in this case) that is successfully used by people other than themselves. Yes, some people who previously used Scala, now use Kotlin. And some people who would've used Scala if Kotlin didn't exist, use Kotlin. Same probably goes for Rust. But there is a big enough market for people that like the intricate and expressive type system that Scala gives you, in combination with the JVM ecosystem. People that think Kotlin is nice, but not expressive enough, for example. People who don't want to deal with Rust's memory management and/or don't have a use for that. People who think Go's simplicity is sometimes more of a burden. Why are people so intent to bash sombody else's language choices?! Go, Rust, Kotlin, Scala are all great languages in different ways. They all cater to different needs, sometimes radically different (Go vs Scala), sometimes subtly different (Kotlin vs Scala). I think there is a market for all of them, and more. And the introduction of a new language (Kotlin for example) does not necessarily spell doom for another (Scala). Let's all enjoy our own tastes and needs, and respect those of others.

lmm 8y ago
The reality is that a language lives or dies by its ecosystem - particularly when it comes to a language like Scala that's in a tightly symbiotic relationship with its IDEs (the next time someone tries to sell you a "visual programming language", look at Scala for a language that makes really effective use of the GUI for programming without compromising the things that make textual programming languages good - see e.g. https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-plugin-2018-1-inline-hints-better-structure-view-improved-refactoring-and-greater-usability/ https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-p... ). Only a few big players can afford the kind of investment it takes to make something like that. So much as I wish it were otherwise, I can't just sit on my island and use Scala because I think it's the best - if the language is to live, I have to convince other people it's the best. I don't begrudge other people feeling the same way about the languages they do like (provided that doesn't fall into dishonesty, as some of the claims from Kotlin advocates about e.g. null and Scala have).
- MichaelMoser123 8y ago
  > if the language is to live, I have to convince other people it's the best Aren't JVM languages interoperable - because they use the same classfile/byte code format? What does it matter if the jar is written in java or scala, as long as it is possible to use the external interface from any of these languages?
  - mason55 8y ago
    No single person can maintain an entire ecosystem around a language. And programming languages have strong network effects. If I think a language is dying then I won’t want to use it because I’ll worry about future support. It becomes a self fulfilling prophecy and a negative feedback loop.
  - dtech 8y ago
    Yes and no. JVM languages can usually use other JVM libraries, but they often aren't idiomatic to that language. Scala can use JVM libraries, but it often feels wrong or cumbersome, e.g. Java is full of mutable builder classes, which I've never once encountered in "native" Scala. The other way around, in Scala you have to be careful if you want your library to be usable from other JVM languages. There's certain Scala features you just cannot use. This is a problem that Kotlin actively markets itself with, they promise 100% Java compatibility all the time, going as far as encouriging to mix Kotlin and Java code in a single project.
    - swirepe 8y ago
      What Scala features can't you use?
      - dtech 8y ago
        implicits mainly, these are objects looked up by the compiler for various purposes e.g. Typeclasses, or how to serialize a specific object to JSON. The Scala 2.8-2.12 collection library was impossible to call from Java, one of the reasons for an upcoming redesign in 2.13.
munificent 8y ago
> Why are people so intent to bash sombody else's language choices?! Partially it's simple tribalism. But part of it is also the rational awareness of the opportunity cost of investing in a language other than the author's preferred one. The more people using language X that I don't like, the fewer people using my preferred language Y. That means fewer libraries I can use, docs I can read, bugs that get fixed, etc. Language ecosystems aren't entirely zero-sum, but they aren't totally orthogonal either.
- DandyDev 8y ago
  That might be true to some extend, but many languages have completely different target audiences. People whose favourite language is Go, will probably not move to Scala (and vice versa). Kotlin vs Scala is an easier to understand competition. In any case, if people want other people to invest in "their language", they should focus on making that language and its ecosystem compelling to use, not bash other languages...
  - deleted 8y ago
    [deleted]
  - geodel 8y ago
    I have seen 2 types of bashers. One which seems typical line of business app developers. They disparage other languages, praise theirs on basic things like IDEs, libs etc. I don't mind these much. However others who approach from position of authority like compiler hackers, language authors themselves, or very senior developers etc. Ideally criticism from them should be more valid but more often than not I have seen they keep making bad faith arguments and justify their hate by precise technical arguments so they can't be challenged by non-technical arguments. It makes vary of their arguments even on topics other than favorite programing language.
  - jnbiche 8y ago
    > People whose favourite language is Go, will probably not move to Scala (and vice versa). Kotlin vs Scala is an easier to understand competition. That said, in terms of language features and type system, Kotlin is arguably closer to Go than it is to Scala. Yes, Kotlin competes with Scala on the JVM, but it's a very different language. Scala is much closer to a language such as OCaml than it is to Kotlin.
AnimalMuppet 8y ago
Agreed. Here's my view on languages: They have strengths and weaknesses. They cater to different needs, as you say. If you have the need for what Rust, say, does, and Rust solves some real problems for you and makes your job a lot easier, then it's kind of natural that you think Rust is wonderful. In fact, what you found is that Rust is wonderful for that problem, not that it's wonderful in general. But it's real easy to think that your situation is more universal than it is, and therefore that Rust (in this example) is this wonderful language that makes all of programming so much better. Once you've fallen into that flawed perspective, then it becomes easy to criticize other languages. Why would you ever want to use Scala? It doesn't have Rust's advantages. But people miss that, if you have a Scala problem rather than a Rust problem, and you pick Rust anyway, it's not going to go well...
didibus 8y ago
Divide and conquer while we rule above the average, enjoying our parenthesis and the riches they bring us. ;)
abc_lisper 8y ago
No! Clojure is da best! jk...
catnaroek 8y ago
> intricate and expressive type system that Scala gives you Most of the complexity of Scala's type system comes from a desire to be compatible with Java, rather than to actually make it more expressive. For example, nominal subtyping is a nightmare for inference, and Scala's designers designed that they would rather sacrifice inference (which contradicts the assumption that the only raison d'être for Scala's complexity is to maximize expressiveness) than Java compatibility. > People who don't want to deal with Rust's memory management and/or don't have a use for that. Rust's memory management actually increases expressiveness in the sense that is usually appreciated by static typing proponents: it expands the space of properties that can be verified by type checking, relative to what other typeful languages offer. It is not immediately clear what Scala offers in this regard, compared to, say, Haskell or OCaml, which are significantly less complex. More easily broken parametricity?
nradov 8y ago
Part of the issue with alternative JVM languages is that there isn't a good standard way to mix them within a single application. There are various compatibility layers for calling foreign functions but nothing baked into the lower-level platform. So that forces a degree of competition and mutual exclusion. Whereas with Microsoft's .NET CLR there's a standard calling convention supported by all the languages. So it's easy to mix and match C#, F#, VB.NET, etc within a single application or reuse libraries. So developers have more freedom to pick the best language for each problem domain. (It looks like Hacker News filters out the Unicode sharp symbol. Why?)
- yawaramin 8y ago
  HN throws away all Unicode symbols.

lmm 8y ago

The reality is that a language lives or dies by its ecosystem - particularly when it comes to a language like Scala that's in a tightly symbiotic relationship with its IDEs (the next time someone tries to sell you a "visual programming language", look at Scala for a language that makes really effective use of the GUI for programming without compromising the things that make textual programming languages good - see e.g. https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-plugin-2018-1-inline-hints-better-structure-view-improved-refactoring-and-greater-usability/ https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-p... ). Only a few big players can afford the kind of investment it takes to make something like that. So much as I wish it were otherwise, I can't just sit on my island and use Scala because I think it's the best - if the language is to live, I have to convince other people it's the best. I don't begrudge other people feeling the same way about the languages they do like (provided that doesn't fall into dishonesty, as some of the claims from Kotlin advocates about e.g. null and Scala have).

MichaelMoser123 8y ago
> if the language is to live, I have to convince other people it's the best Aren't JVM languages interoperable - because they use the same classfile/byte code format? What does it matter if the jar is written in java or scala, as long as it is possible to use the external interface from any of these languages?
- mason55 8y ago
  No single person can maintain an entire ecosystem around a language. And programming languages have strong network effects. If I think a language is dying then I won’t want to use it because I’ll worry about future support. It becomes a self fulfilling prophecy and a negative feedback loop.
- dtech 8y ago
  Yes and no. JVM languages can usually use other JVM libraries, but they often aren't idiomatic to that language. Scala can use JVM libraries, but it often feels wrong or cumbersome, e.g. Java is full of mutable builder classes, which I've never once encountered in "native" Scala. The other way around, in Scala you have to be careful if you want your library to be usable from other JVM languages. There's certain Scala features you just cannot use. This is a problem that Kotlin actively markets itself with, they promise 100% Java compatibility all the time, going as far as encouriging to mix Kotlin and Java code in a single project.
  - swirepe 8y ago
    What Scala features can't you use?
    - dtech 8y ago
      implicits mainly, these are objects looked up by the compiler for various purposes e.g. Typeclasses, or how to serialize a specific object to JSON. The Scala 2.8-2.12 collection library was impossible to call from Java, one of the reasons for an upcoming redesign in 2.13.

munificent 8y ago

> Why are people so intent to bash sombody else's language choices?! Partially it's simple tribalism. But part of it is also the rational awareness of the opportunity cost of investing in a language other than the author's preferred one. The more people using language X that I don't like, the fewer people using my preferred language Y. That means fewer libraries I can use, docs I can read, bugs that get fixed, etc. Language ecosystems aren't entirely zero-sum, but they aren't totally orthogonal either.

DandyDev 8y ago
That might be true to some extend, but many languages have completely different target audiences. People whose favourite language is Go, will probably not move to Scala (and vice versa). Kotlin vs Scala is an easier to understand competition. In any case, if people want other people to invest in "their language", they should focus on making that language and its ecosystem compelling to use, not bash other languages...
- deleted 8y ago
  [deleted]
- geodel 8y ago
  I have seen 2 types of bashers. One which seems typical line of business app developers. They disparage other languages, praise theirs on basic things like IDEs, libs etc. I don't mind these much. However others who approach from position of authority like compiler hackers, language authors themselves, or very senior developers etc. Ideally criticism from them should be more valid but more often than not I have seen they keep making bad faith arguments and justify their hate by precise technical arguments so they can't be challenged by non-technical arguments. It makes vary of their arguments even on topics other than favorite programing language.
- jnbiche 8y ago
  > People whose favourite language is Go, will probably not move to Scala (and vice versa). Kotlin vs Scala is an easier to understand competition. That said, in terms of language features and type system, Kotlin is arguably closer to Go than it is to Scala. Yes, Kotlin competes with Scala on the JVM, but it's a very different language. Scala is much closer to a language such as OCaml than it is to Kotlin.

AnimalMuppet 8y ago

Agreed. Here's my view on languages: They have strengths and weaknesses. They cater to different needs, as you say. If you have the need for what Rust, say, does, and Rust solves some real problems for you and makes your job a lot easier, then it's kind of natural that you think Rust is wonderful. In fact, what you found is that Rust is wonderful for that problem, not that it's wonderful in general. But it's real easy to think that your situation is more universal than it is, and therefore that Rust (in this example) is this wonderful language that makes all of programming so much better. Once you've fallen into that flawed perspective, then it becomes easy to criticize other languages. Why would you ever want to use Scala? It doesn't have Rust's advantages. But people miss that, if you have a Scala problem rather than a Rust problem, and you pick Rust anyway, it's not going to go well...

didibus 8y ago

Divide and conquer while we rule above the average, enjoying our parenthesis and the riches they bring us. ;)

abc_lisper 8y ago

No! Clojure is da best! jk...

catnaroek 8y ago

> intricate and expressive type system that Scala gives you Most of the complexity of Scala's type system comes from a desire to be compatible with Java, rather than to actually make it more expressive. For example, nominal subtyping is a nightmare for inference, and Scala's designers designed that they would rather sacrifice inference (which contradicts the assumption that the only raison d'être for Scala's complexity is to maximize expressiveness) than Java compatibility. > People who don't want to deal with Rust's memory management and/or don't have a use for that. Rust's memory management actually increases expressiveness in the sense that is usually appreciated by static typing proponents: it expands the space of properties that can be verified by type checking, relative to what other typeful languages offer. It is not immediately clear what Scala offers in this regard, compared to, say, Haskell or OCaml, which are significantly less complex. More easily broken parametricity?

nradov 8y ago

Part of the issue with alternative JVM languages is that there isn't a good standard way to mix them within a single application. There are various compatibility layers for calling foreign functions but nothing baked into the lower-level platform. So that forces a degree of competition and mutual exclusion. Whereas with Microsoft's .NET CLR there's a standard calling convention supported by all the languages. So it's easy to mix and match C#, F#, VB.NET, etc within a single application or reuse libraries. So developers have more freedom to pick the best language for each problem domain. (It looks like Hacker News filters out the Unicode sharp symbol. Why?)

yawaramin 8y ago
HN throws away all Unicode symbols.