7 ms·

Let's say you want a GC'd language (no C, C++) on *nix (no C#), good/varied libraries to work with (no esoteric languages), good performance (no Ruby, Python),

by fizx 10y ago

Let's say you want a GC'd language (no C, C++) on *nix (no C#), good/varied libraries to work with (no esoteric languages), good performance (no Ruby, Python), reasonable options for implementing concurrency (no Javascript), what's left? Looks like a JVM language (Java, Scala, etc), or Golang. Java has better tooling and more mature implementations. I personally find modern Java nicer to write than Golang (though Scala nicer than both). These days, it comes down to whether the JVM memory overhead is a big deal on the specific project, and if not, for the class of projects discussed in the previous paragraph, I'm probably choosing Scala (but if my teammates object, then it's back to Java).

jsmthrowaway 10y ago
> Let's say you want a GC'd language (no C, C++) IOW, "Let's say you want largely random pauses to impact latency non-deterministically." I'm not knocking GC, but it has serious consequences in systems that make this a weird assumption with which to start, particularly the "big" GC languages that you named. Scala in particular with its immutability generates a lot of garbage if you are not careful, and we were constantly fighting GC pressure (and, indirectly, our achievable concurrency and efficiency) at a household name Scala app. The number of JVM developers who are aware of this and capable with the memory subsystem -- i.e., off-heap strategies such as that used in Flink (relevantly) and some of the clever speedups in netty -- are dwarfed by the number of JVM developers in the whole, so you really need someone who understands these problems to efficiently scale a JVM language. There are better systems languages if you can move away from GC, such as Rust. And modern C++ is fantastic for systems, and it's too bad it gets overlooked because of bam, your first assumption there. Most systems at Google are in C++ because they invested into the infrastructure that you need to support it. It should tell you something that they're heavily involved in each new version of C++. (I'm talking about systems, not applications. GC is a viable tradeoff for programmer productivity in applications.)
- fizx 10y ago
  I'm excited for Rust for the reasons you talk about, but when I tried it a year ago, FFI was broken. I'd like to find a reason to retry it soon!
  - steveklabnik 10y ago
    Do you remember how it was broken? I wasn't aware of any problems, but if you can remember, I can give you an update.
- snaky 10y ago
  > you really need someone who understands these problems to efficiently scale a JVM language Yes. That's not a problem to find and hire one or two of these guys to write a core. And then hire a ton of regular Java developers to write a ton of code you need around that core, educated and managed by those two smart guys. Compare it to the problem you have going C, C++, Rust, Nim way. Now you need to hire a ton of guys who can write good C++ code (because it must be good to not to crash every 5 seconds, at least), or even worse - a ton of guys who can write any (not even good) Nim code.
  - jsmthrowaway 10y ago
    Your entire second paragraph indicates to me that you haven't spent time at a well-oiled C++ shop or potentially haven't worked with modern C++ at all. What does "crash every 5 seconds" even mean? Do you think outside of Java we are all sitting around pounding rocks together and dealing with segfaults all day long? Are you saying JVM languages don't NPE in poor hands? There are three focus areas of wrongness in your comment (maybe four if I'm feeling particularly culturally trolly) but I'll stick with that one and leave the others to others.
    - coredog64 10y ago
      I think he is casting aspersions on the average programmer. I'm on a significant chunk of PRs across projects at my employer and I have seen crazy crazy shit from Java devs with years of experience. In some cases these same devs hold Java certifications from Sun/Oracle. I shudder to think of what would happen if they decided to have these guys write C or C++.
- jedisfullofit 10y ago
  "Scala in particular with its immutability generates a lot of garbage if you are not careful, and we were constantly fighting GC pressure (and, indirectly, our achievable concurrency and efficiency) at a household name Scala app. The number of JVM developers who are aware of this and capable with the memory subsystem -- i.e., off-heap strategies such as that used in Flink (relevantly) and some of the clever speedups in netty -- are dwarfed by the number of JVM developers in the whole, so you really need someone who understands these problems to efficiently scale a JVM language." Jed, once again you are laying claim to experience you do not have. If you ever once had touched Scala at Foursquare it would be a different story. This is just a bunch of tired platitudes.
insulanian 10y ago
> on nix (no C#) C# runs absolutely fine on nix.
- int_handler 10y ago
  Yes, it is possible to run C# on *nix using Mono but the ecosystem isn't as rich as that of Java.
PeCaN 10y ago
> what's left? - Erlang (this fits your criteria at least as Java...) - OCaml (concurrency isn't the best) - Haskell (also fits your criteria very well) - D (easy to use C libraries and sometimes C++) - Rust (not GCed, but why is GCed a requirement?) - Mercury (admittedly pretty obscure, but using C libraries is easy enough and it fits everything else) Java only seems like a good choice if you ignore all the languages that are a better choice than Java. IMO Erlang seems like the choice here (or Elixir if you don't like Erlang syntax).
- mbreese 10y ago
  Let's also say that you want to be able to hire programmers to write and maintain it. And it would be nice to make it open to many more people so they could find and fix bugs. After that, what's left? At the moment, none of the above languages have any significant talent pool to draw from. If you're operating at "Twitter-scale" (I guess that's now a thing), you also need to be able to spin up a team of people that can get to work quickly without having to learn a language as they go. That eliminates a great number of languages just for logistical reasons. Rust might get there (and I hope it does!), but it's not there yet. Maybe Twitter already has a significant number of skilled Java engineers, so they decided to use what they already knew really well. There's nothing wrong with that. Choosing any of the other languages you listed would have been a far riskier strategy.
- flippant 10y ago
  - Erlang/Elixir - OP mentioned performance. Erlang is terrible for CPU-bound tasks. - Haskell - OP said non-esoteric. - Rust - There's a significant ramp up before you learn to deal with the compiler and lifetimes.
  - PeCaN 10y ago
    > Erlang Erlang's CPU performance is not bad IME (though admittedly I can't think of anything I've implemented in both Erlang and Java to compare). But that's beside the point; you pick Erlang for networked and I/O bound tasks. Twitter mentioned running Heron on several hundred machines—at that scale, single-thread performance starts to matter less and Erlang's scaling efficiency closes the gap. > Haskell Haskell may have been esoteric in 2005, but it's hardly so anymore. (Also, I mention Mercury, and Haskell is the language you decide is too esoteric‽) > Rust So you're saying they wouldn't use it because they didn't know it. I suspect that's the real reason they chose Java—not because it is necessarily the best language suited for the task, but because it's the best of the languages Heron's developers knew.
deleted 10y ago
[deleted]

by fizx 10y ago

jsmthrowaway 10y ago

> Let's say you want a GC'd language (no C, C++) IOW, "Let's say you want largely random pauses to impact latency non-deterministically." I'm not knocking GC, but it has serious consequences in systems that make this a weird assumption with which to start, particularly the "big" GC languages that you named. Scala in particular with its immutability generates a lot of garbage if you are not careful, and we were constantly fighting GC pressure (and, indirectly, our achievable concurrency and efficiency) at a household name Scala app. The number of JVM developers who are aware of this and capable with the memory subsystem -- i.e., off-heap strategies such as that used in Flink (relevantly) and some of the clever speedups in netty -- are dwarfed by the number of JVM developers in the whole, so you really need someone who understands these problems to efficiently scale a JVM language. There are better systems languages if you can move away from GC, such as Rust. And modern C++ is fantastic for systems, and it's too bad it gets overlooked because of bam, your first assumption there. Most systems at Google are in C++ because they invested into the infrastructure that you need to support it. It should tell you something that they're heavily involved in each new version of C++. (I'm talking about systems, not applications. GC is a viable tradeoff for programmer productivity in applications.)

fizx 10y ago
I'm excited for Rust for the reasons you talk about, but when I tried it a year ago, FFI was broken. I'd like to find a reason to retry it soon!
- steveklabnik 10y ago
  Do you remember how it was broken? I wasn't aware of any problems, but if you can remember, I can give you an update.
snaky 10y ago
> you really need someone who understands these problems to efficiently scale a JVM language Yes. That's not a problem to find and hire one or two of these guys to write a core. And then hire a ton of regular Java developers to write a ton of code you need around that core, educated and managed by those two smart guys. Compare it to the problem you have going C, C++, Rust, Nim way. Now you need to hire a ton of guys who can write good C++ code (because it must be good to not to crash every 5 seconds, at least), or even worse - a ton of guys who can write any (not even good) Nim code.
- jsmthrowaway 10y ago
  Your entire second paragraph indicates to me that you haven't spent time at a well-oiled C++ shop or potentially haven't worked with modern C++ at all. What does "crash every 5 seconds" even mean? Do you think outside of Java we are all sitting around pounding rocks together and dealing with segfaults all day long? Are you saying JVM languages don't NPE in poor hands? There are three focus areas of wrongness in your comment (maybe four if I'm feeling particularly culturally trolly) but I'll stick with that one and leave the others to others.
  - coredog64 10y ago
    I think he is casting aspersions on the average programmer. I'm on a significant chunk of PRs across projects at my employer and I have seen crazy crazy shit from Java devs with years of experience. In some cases these same devs hold Java certifications from Sun/Oracle. I shudder to think of what would happen if they decided to have these guys write C or C++.
jedisfullofit 10y ago
"Scala in particular with its immutability generates a lot of garbage if you are not careful, and we were constantly fighting GC pressure (and, indirectly, our achievable concurrency and efficiency) at a household name Scala app. The number of JVM developers who are aware of this and capable with the memory subsystem -- i.e., off-heap strategies such as that used in Flink (relevantly) and some of the clever speedups in netty -- are dwarfed by the number of JVM developers in the whole, so you really need someone who understands these problems to efficiently scale a JVM language." Jed, once again you are laying claim to experience you do not have. If you ever once had touched Scala at Foursquare it would be a different story. This is just a bunch of tired platitudes.

insulanian 10y ago

> on nix (no C#) C# runs absolutely fine on nix.

int_handler 10y ago
Yes, it is possible to run C# on *nix using Mono but the ecosystem isn't as rich as that of Java.

PeCaN 10y ago

> what's left? - Erlang (this fits your criteria at least as Java...) - OCaml (concurrency isn't the best) - Haskell (also fits your criteria very well) - D (easy to use C libraries and sometimes C++) - Rust (not GCed, but why is GCed a requirement?) - Mercury (admittedly pretty obscure, but using C libraries is easy enough and it fits everything else) Java only seems like a good choice if you ignore all the languages that are a better choice than Java. IMO Erlang seems like the choice here (or Elixir if you don't like Erlang syntax).

mbreese 10y ago
Let's also say that you want to be able to hire programmers to write and maintain it. And it would be nice to make it open to many more people so they could find and fix bugs. After that, what's left? At the moment, none of the above languages have any significant talent pool to draw from. If you're operating at "Twitter-scale" (I guess that's now a thing), you also need to be able to spin up a team of people that can get to work quickly without having to learn a language as they go. That eliminates a great number of languages just for logistical reasons. Rust might get there (and I hope it does!), but it's not there yet. Maybe Twitter already has a significant number of skilled Java engineers, so they decided to use what they already knew really well. There's nothing wrong with that. Choosing any of the other languages you listed would have been a far riskier strategy.
flippant 10y ago
- Erlang/Elixir - OP mentioned performance. Erlang is terrible for CPU-bound tasks. - Haskell - OP said non-esoteric. - Rust - There's a significant ramp up before you learn to deal with the compiler and lifetimes.
- PeCaN 10y ago
  > Erlang Erlang's CPU performance is not bad IME (though admittedly I can't think of anything I've implemented in both Erlang and Java to compare). But that's beside the point; you pick Erlang for networked and I/O bound tasks. Twitter mentioned running Heron on several hundred machines—at that scale, single-thread performance starts to matter less and Erlang's scaling efficiency closes the gap. > Haskell Haskell may have been esoteric in 2005, but it's hardly so anymore. (Also, I mention Mercury, and Haskell is the language you decide is too esoteric‽) > Rust So you're saying they wouldn't use it because they didn't know it. I suspect that's the real reason they chose Java—not because it is necessarily the best language suited for the task, but because it's the best of the languages Heron's developers knew.

deleted 10y ago

[deleted]