Hacker News new | past | comments | ask | show | jobs | submit login

> for many Go is the only compiled language they ever used

That, or it can be read as "in the family of web-friendly languages". The only other "fast" language widely used for the web is Java.




C++, .NET also come to mind in the widely area, with OCaml, Haskell failing under the not so widely, but fast umbrella.


O'caml and Haskell are extremely niche in the web server world, and are not especially faster than go. C# is not blazingly fast either. They all seem to be in the same ballpark.


They are all faster than Go in case you haven't been paying attention.


I've been paying a lot of attention and, in my experience (but also according to the highly biased benchmark game), C#/Java/OCaml/Haskell/Go are in the same league, i.e usually 3-10 times slower than C/C++/Ada/Rust/D, and 3-10 times faster than "scripting" languages like Python/PHP/Ruby/Perl.

With (in my experience) go being a little faster than java and haskell, and o'caml being slightly faster than anyone, but nothing significative enough for me to expect an article titled "my Java webapp was too slow so I rewrote it in O'Caml" anytime soon.

Benchmarking is very relative, though. I'd be glad to read evidence showing go is significantly slower than any of those in some domain.


Techempower is where real benchmarks live, the highly biased benchmark game examples aren't all using the latest features or even best algorithms.


> …examples aren't all using the latest features…

You know you can contribute what you consider to be better examples — https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

> …or even best algorithms…

Wouldn't that make the algorithm the difference ;-)


Thanks a lot, didn't know techempower. Go seems to behave pretty well in these benchmarks, though.


> …in my experience (but also according to the highly biased benchmark game)…

You seem to be saying that what you see on the benchmarks game matches your experience, which makes your "highly biased" claim kind-of strange.

Please show something on that website that is "highly biased".


And java is a memory hog quite painful to deploy and tune.


Memory hog only by those that don't know what they are doing and happilly new everywhere.

Yes it is hard to tune, but not so much different than playing with C or C++ compilation switches, across each compiler that is being used in production.


> Memory hog only by those that don't know what they are doing and happilly new everywhere.

Go uses an order of magnitude less memory for most type of workloads though. Also you don't tune c++ binaries delivered to you. You have to tune the JVM's option to death for big apps. I can't count the number of incidents "solved" by raising the Xmx param.


I tune C++ compilers, just like I tune Java compilers, in both cases I can decide to do it during AOT compilation or at a later moment.

The big question is how properly those big apps were coded.

Go doesn't run Fintech servers, while Java keeps replacing C++ servers. Yes, one needs to code Java with low level tricks like C++, but it is possible and there are many performance experts doing it.

How many Fintech servers are running on Go?


> I tune C++ compilers, just like I tune Java compilers, in both cases I can decide to do it during AOT compilation or at a later moment

How many customers run self-compiled, say mysql binaries? Or mongodb? An tiny minority. Now how many tune cassandra or hadoop jvms? A big chunk.

You can use niche cases to make a point (fintech is almost the textbook definition of a niche software use case), however what you say is plain wrong most of the time.

Also, I've managed thousands of c++ and thousands of java processes. I'd take c++ ones over java any day.


Depends on how many use Gentoo, for example.

Proper Cassandra and Hadoop deployments are as niche as Fintech, the large majority could solve their problems with UNIX command line tools.

On my world the team manages deployments, I rather take Java over C++ compilation times, and having tools like Mission Control to monitor cluster performance on production servers.


Yes, launching a new server/executable in java is a PITA dur to the JVM warmup (at least it was a few years ago, don't know whether they improved that point or not).


Don't forget that you also have to install and update the JVM. We admins don't like that.


Only those that don't know how to bundle the JVM with the application or make use of a commercial AOT compiler to native code.


You prove my point, it requires specific knowledge full of gotchas.


As team lead I consider having the interest to master the tooling part of the job requirements and respective evaluation, not specific knowledge full of gothas.


Only for those that don't use a JVM with either AOT compilation or JIT caching.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: