4 ms·

Save yourself the pain and go with Scala and the JVM ... mature platform with battle tested GCs, all the libraries and concurrency idioms you'll ever need and a

Save yourself the pain and go with Scala and the JVM ... mature platform with battle tested GCs, all the libraries and concurrency idioms you'll ever need and a modern FP language designed for scale.

swah 13y ago
Scala problems (in the old days): - You can't find people to work on it - Unbounded complexity, type-masturbation - Slow compilation (you need a better computer/SSD) - Might as well use Java, the tooling for Java is great Do you know if those are still true?
- dubbledidu 13y ago
  It has gotten a lot better on all fronts.
- asdasf 13y ago
  >You can't find people to work on it If you felt that was a problem before, you will almost certainly still feel that way. >Unbounded complexity, type-masturbation No idea what you mean. >Slow compilation Still terrible. >Might as well use Java, the tooling for Java is great The tooling for java is better, but java the language is unbearable.
TylerE 13y ago
Only if you don't mind paying approximately an order of magnitude penalty in RAM usage, which has long been an achilles heel of JVM languages. http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=scala&lang2=go&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
- dubbledidu 13y ago
  It uses exactly as much memory as you specify. It would be pretty stupid to have plenty of RAM and NOT using it. With enough memory GC becomes essentially free, by not having to do any work.
  - TylerE 13y ago
    Nonsense. I'm talking about the SAME data taking more memory to represent. Plus, all things being equal a larger memory space will take more time to GC, and GCs become longer, not shorter. The JVM does things suboptimally in a number of ways. Object memory overhead is relatively high - typically 8 or 16 bytes per object, strings as UTF-16 (vs Go's UTF-8), etc. It really adds up, and funtional languages tend to churn lots of GC.
    - pcwalton 13y ago
      > strings as UTF-16 (vs Go's UTF-8), etc. Strings aren't traced, so that has no impact on GC time.
      - TylerE 13y ago
        It does, however, impact memory usage quite substantially if your data is string-heavy, which most web-apps are.
    - dubbledidu 13y ago
      Wrong, wrong, wrong and wrong.
    - bad_user 13y ago
      This is the first time I ever heard anybody complain about UTF-16, citing it as the reason for why the JVM consumes more memory, which is of course bullshit. One reason for why JVM apps appear to consume so much memory is because the JVM allocates more memory than it needs. It does so because the garbage collectors are generational and compacting (well, CMS is non-compacting, but when the memory gets too fragmented, the VM does fallback to a stop-the-world compaction of memory). In a server context the JVM also does not release the free memory it has to the operating system, because allocating that memory in the first place is expensive and so it keeps it for later usage ... the result is that memory allocation on top of the JVM is as efficient as stack allocation, since all the JVM does is to increment a pointer, and deallocation of short-lived objects is nearly as innexpensive as stack unwinding, since the GC is generational and deallocates stuff in bulk. These capabilities come at a cost, as the GC also needs memory to move things around, but it's also memory well spent (e.g. Firefox has been plagued by memory fragmentation for years). Speaking of Golang, it has some of the shittiest GCs in existence ... non-generational, non-compacting, non-concurrent and "mostly precise". Of course, it used to be fully conservative, which meant you could easily end up with really nasty memory leaks on 32bits systems, because the GC wasn't able to make a difference between Ints and pointers. The only thing saving Go is the ability to work in many cases with the stack, alleviating the stress that the GC faces, but this low-level capability will also prevent it from having a good GC anytime soon, like the JVM has had for years. And really, in terms of memory usage, you should see how the JVM's CMS or G1 behaves in production, as it makes all the difference. Our web-service (written in Scala) that's being hit by more than 30,000 requests per second that must be served in under 100ms per request, was at some point hosted on Heroku, using only 8 instances, instances which have less than 400 MB of usable RAM. It was absolutely superb seeing it in action, as the processes themselves were not exceeding 200 MB of real usage - Heroku even told us that we are costing them more than we are paying them. So yeah, you can talk bullshit about strings being UTF-16, but the real wold disagrees.
- bad_user 13y ago
  In a server-side context the JVM tends to be the most memory efficient out of all platforms that make use of GC. Here's for example the comparison of Ruby MRI with JRuby, showing a massive difference in memory usage, and yet many Ruby developers choose to deploy their apps on top of JRuby precisely because of much better memory usage, which is why your reference to these benchmarks is basically useless: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=jruby&lang2=yarv&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
ChikkaChiChi 13y ago
The problem is the Mobius strip of reasoning you go through when you start to punish yourself into picking the 'best' language. Different tools for this and that sure...but I think ultimately Golang in the long run will see a more widespread adoption rate. There will always be better tools, you just can't beat yourself up trying to pre-optimize for each one per project.
asdasf 13y ago
>a modern FP language Scala is many things, but that is not one of them. Scala is an OO language with some FP influence.

Save yourself the pain and go with Scala and the JVM ... mature platform with battle tested GCs, all the libraries and concurrency idioms you'll ever need and a modern FP language designed for scale.

swah 13y ago

Scala problems (in the old days): - You can't find people to work on it - Unbounded complexity, type-masturbation - Slow compilation (you need a better computer/SSD) - Might as well use Java, the tooling for Java is great Do you know if those are still true?

dubbledidu 13y ago
It has gotten a lot better on all fronts.
asdasf 13y ago
>You can't find people to work on it If you felt that was a problem before, you will almost certainly still feel that way. >Unbounded complexity, type-masturbation No idea what you mean. >Slow compilation Still terrible. >Might as well use Java, the tooling for Java is great The tooling for java is better, but java the language is unbearable.

TylerE 13y ago

Only if you don't mind paying approximately an order of magnitude penalty in RAM usage, which has long been an achilles heel of JVM languages. http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=scala&lang2=go&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

dubbledidu 13y ago
It uses exactly as much memory as you specify. It would be pretty stupid to have plenty of RAM and NOT using it. With enough memory GC becomes essentially free, by not having to do any work.
- TylerE 13y ago
  Nonsense. I'm talking about the SAME data taking more memory to represent. Plus, all things being equal a larger memory space will take more time to GC, and GCs become longer, not shorter. The JVM does things suboptimally in a number of ways. Object memory overhead is relatively high - typically 8 or 16 bytes per object, strings as UTF-16 (vs Go's UTF-8), etc. It really adds up, and funtional languages tend to churn lots of GC.
  - pcwalton 13y ago
    > strings as UTF-16 (vs Go's UTF-8), etc. Strings aren't traced, so that has no impact on GC time.
    - TylerE 13y ago
      It does, however, impact memory usage quite substantially if your data is string-heavy, which most web-apps are.
  - dubbledidu 13y ago
    Wrong, wrong, wrong and wrong.
  - bad_user 13y ago
    This is the first time I ever heard anybody complain about UTF-16, citing it as the reason for why the JVM consumes more memory, which is of course bullshit. One reason for why JVM apps appear to consume so much memory is because the JVM allocates more memory than it needs. It does so because the garbage collectors are generational and compacting (well, CMS is non-compacting, but when the memory gets too fragmented, the VM does fallback to a stop-the-world compaction of memory). In a server context the JVM also does not release the free memory it has to the operating system, because allocating that memory in the first place is expensive and so it keeps it for later usage ... the result is that memory allocation on top of the JVM is as efficient as stack allocation, since all the JVM does is to increment a pointer, and deallocation of short-lived objects is nearly as innexpensive as stack unwinding, since the GC is generational and deallocates stuff in bulk. These capabilities come at a cost, as the GC also needs memory to move things around, but it's also memory well spent (e.g. Firefox has been plagued by memory fragmentation for years). Speaking of Golang, it has some of the shittiest GCs in existence ... non-generational, non-compacting, non-concurrent and "mostly precise". Of course, it used to be fully conservative, which meant you could easily end up with really nasty memory leaks on 32bits systems, because the GC wasn't able to make a difference between Ints and pointers. The only thing saving Go is the ability to work in many cases with the stack, alleviating the stress that the GC faces, but this low-level capability will also prevent it from having a good GC anytime soon, like the JVM has had for years. And really, in terms of memory usage, you should see how the JVM's CMS or G1 behaves in production, as it makes all the difference. Our web-service (written in Scala) that's being hit by more than 30,000 requests per second that must be served in under 100ms per request, was at some point hosted on Heroku, using only 8 instances, instances which have less than 400 MB of usable RAM. It was absolutely superb seeing it in action, as the processes themselves were not exceeding 200 MB of real usage - Heroku even told us that we are costing them more than we are paying them. So yeah, you can talk bullshit about strings being UTF-16, but the real wold disagrees.
bad_user 13y ago
In a server-side context the JVM tends to be the most memory efficient out of all platforms that make use of GC. Here's for example the comparison of Ruby MRI with JRuby, showing a massive difference in memory usage, and yet many Ruby developers choose to deploy their apps on top of JRuby precisely because of much better memory usage, which is why your reference to these benchmarks is basically useless: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=jruby&lang2=yarv&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

ChikkaChiChi 13y ago

The problem is the Mobius strip of reasoning you go through when you start to punish yourself into picking the 'best' language. Different tools for this and that sure...but I think ultimately Golang in the long run will see a more widespread adoption rate. There will always be better tools, you just can't beat yourself up trying to pre-optimize for each one per project.

asdasf 13y ago

>a modern FP language Scala is many things, but that is not one of them. Scala is an OO language with some FP influence.