141–150 of 171 posts
I have used Java since the beginning (and I have written several Java books). I have had very few portability problems. The JVM is a great ecosystem that supports several fine programming languages.
Earlier quoted context omitted.
I have a hard time believing anything can beat or even match the garbage collection performance of the JVM. Not that there is something special about the JVM, just that there have been _so_ many smart people working on the problem for so long now. And for good performance doing server tasks (ie, not computational tasks) exceptional GC is a must. Can a GO program handle a workload that creates tens/hundreds of thousan…
Remember Go doesn't have objects, it only has structs which are most likely (and should be, but I haven't verified) much lighter weight than the objects you might be used to in Java. As far as the creating tens/hundreds of thousands of structs per second for weeks or months without leaking memory, I'll get back to you on that once my code has been active that long ;)
Earlier quoted context omitted.
My day job involves working with Java and C++ on 10+ year old systems. All of my hobby or side projects are in Go these days with occasional diversions into haskell, ML or various Lisps. So I'll try to impart some understanding of why I would switch to Go from Java or C++. First lets get some things out of the way. Go is fast enough and getting faster very quickly and it definitely has a smaller memory footprint. So…
Oh, I don't doubt many things can be done much better in other languages than Java, only why stop at Go? Clojure pretty much hits every single one of your requirements, it's more modern and expressive than Go, gets concurrency better, and it's about as slower than Go as Go is slower than Java -- and getting faster. Also, you don't have to give up the monitoring and instrumentation the JVM gives you, as well as the va…
I recently (more or less) shut down my consulting business to do other things and since I no longer need (so much) to fit in with customer's tool chains, I decided on Clojure as a great general purpose language that is also a lot of fun to develop with. I could make the same comment about Scala or JRuby if I had chosen either of those fine languages.
Really, the JVM ecosystem rocks.
Earlier quoted context omitted.
They sure do. Slower than Scala and requiring more code and lacking the awesome power of the JVM. Great choice, indeed.
Yeah- that is great as long as you don't care about using 30x times more memory.... The awesome bloat cough I mean power of the JVM in action. Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... It will be interesting to re-visit this when Go 1.1 is out as well. Go being even younger than Scala has a lot of low hanging optimization fruit. :) P.S. If Go didn't exist I would still be using Java…
k-nucleotide 260,908KB vs Java program 167,924KB
regex-dna 679,836KB vs Java program 621,712KB
binary-trees 565,076KB vs Java program 528,364KB
and not much difference for this
reverse-complement 249,304KB vs Java program 298,904KB
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
For tiny tiny programs that only allocate a few KB, the default JVM allocation swamps what the programs use -- that changes when programs need to allocate memory.
Earlier quoted context omitted.
Yeah- that is great as long as you don't care about using 30x times more memory.... The awesome bloat cough I mean power of the JVM in action. Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... It will be interesting to re-visit this when Go 1.1 is out as well. Go being even younger than Scala has a lot of low hanging optimization fruit. :) P.S. If Go didn't exist I would still be using Java…
Not to mention the frankly idiotic JVM startup time that becomes a nightmare if you are just trying to make a commandline tool. And no, don't bother mentioning nailgun or the like. Those cures are worse than the illness.
The benchmarks game measurements posted by voidlogic include JVM startup time and yet many of the Scala programs are faster than the corresponding Go programs, when the programs run for seconds.
So a Go n-body program can be faster than a Scala n-body program at 0.33secs over a small workload, but then over a larger workload take 32.1secs compared to 23.5secs for the Scala program.
http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
Earlier quoted context omitted.
>> * I actually don't think immutability is as key to concurrency as it gets hyped to be. Clojure which I've used and enjoyed does tend to get in your way with the immutability by default.* I don't want to join into a language war, but I wanted to point out two things with this statement: 1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this…
> 1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this war, at least in the research realm, 30 years ago. Maybe, but concurrency based on mutability seems to have won this war in the real world these past thirty years. Immutable systems might be easier to design in theory but we haven't seen this proven in the battle field yet, and the fact…
Earlier quoted context omitted.
Not to mention the frankly idiotic JVM startup time that becomes a nightmare if you are just trying to make a commandline tool. And no, don't bother mentioning nailgun or the like. Those cures are worse than the illness.
When your commandline tool needs several seconds CPU to complete the task, JVM startup time is irrelevant. The benchmarks game measurements posted by voidlogic include JVM startup time and yet many of the Scala programs are faster than the corresponding Go programs, when the programs run for seconds. So a Go n-body program can be faster than a Scala n-body program at 0.33secs over a small workload, but then over a la…
And mine do not. Furthermore, when you program is but one of many steps in a pipeline, but is not the bottleneck, startup time can have a very noticeable effect.
I've heard a million reasons why JVM startup times do not matter. You are telling me nothing new.
If anyone is interested in learning go, my site has a compiled list of tutorials and so on http://pineapple.io/resources/tagged/go-language?type=tutori...
Earlier quoted context omitted.
When your commandline tool needs several seconds CPU to complete the task, JVM startup time is irrelevant. The benchmarks game measurements posted by voidlogic include JVM startup time and yet many of the Scala programs are faster than the corresponding Go programs, when the programs run for seconds. So a Go n-body program can be faster than a Scala n-body program at 0.33secs over a small workload, but then over a la…
> When your commandline tool needs several seconds CPU to complete the task And mine do not. Furthermore, when you program is but one of many steps in a pipeline, but is not the bottleneck, startup time can have a very noticeable effect. I've heard a million reasons why JVM startup times do not matter. You are telling me nothing new.
Earlier quoted context omitted.
Funny thing about Go is that as a compiled language, folks often need to send the source-code to the deployment servers to compile on them too. I seem to recall that deployment servers shouldn't need to have development tools which were themselves exposing the servers to bad intention by bad folks. It's just hard to keep the separation I guess. This is what systems administrators with grey beards thought in the 1990s…
Well back in the 90s we kept the machines lean more because disk space was fucking expensive.