Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

>There is nothing, absolutely nothing, that you can do in Go that you can not do via libraries in Java

Yes there is.

You can run thousands of concurrent goroutines. Creating thousands of threads in Java will bring the system to its knees. java.util.concurrent doesn't solve the stack size problem.

You can have compact structured value types in Go but not in Java, meaning Java will always eat a lot more memory than Go.

View on HN

In Java you can use executors and thread pools to "start thousands of threads" in the same way those "thousends of concurrent goroutines" are running "in the same time" on a modern 16 core cpu.

That's not true at all. Each goroutine has its own variable sized stack whereas Runnable objects in Java don't have a stack of their own. They use the thread's stack. So as long as a Runnable uses its stack (that is the run() method hasn't finished), the thread cannot be used by other Runnables.

So, in Go you can have thousands active function invocations (i.e tens of thousands of stack frames on thousands of stacks) at the same time and they do not occupy thousands of threads. You can't do that in Java.

> Each goroutine has its own variable sized stack whereas Runnable objects in Java don't have a stack of their own.

Which JVM or native Java compiler are you talking about? This is implementation specific.

Which ones give stacks to each runnable? Does Oracle? Does OpenJDK?

Oracle and OpenJDK are just two JVMs.

I know at least the following JVMs

Oracle JVM

OpenJDK JVM

Metro JVM

IBM JVM

Aonix JVM

Cacao VM

Squawk VM

Jikes VM

VMKit

BlueRay VMs

Excelsior JET Java native compiler

GCJ native Java compiler

Aonix Perc Java compiler

... (many many others)

I doubt every single of the above implementations does threading the same way.

So have you checked if any of these do what you claim they could do?

And you have done it?

Why would I? I said none of the implementations I know of do what you say. If you do know an implementation that does, then please tell me which one.

No you did not. You stated that is not possible in Java at all regardless of the implementation. I don't see any mention of " none of the implementations I know of" on your comment.

<quote> That's not true at all. Each goroutine has its own variable sized stack whereas Runnable objects in Java don't have a stack of their own. They use the thread's stack. So as long as a Runnable uses its stack (that is the run() method hasn't finished), the thread cannot be used by other Runnables.

You are being deliberately dense. If no existing JVM gives runnable objects their own stack, then it's impossible for a java developer to create thousands of threads (without creating their own JVM, which is totally unreasonable 99% of the time). It's a practical impossibility. Is that so much worse than a technical one?

I said it here: http://news.ycombinator.com/item?id=4707344 12 hours ago in a direct reply to your question.

I am really sorry for my reaction and excuse myself for it.

I have missed that and got carried away in Internet discussion style.

Sorry about that, somehow I got it wrong and blindly carried on discussing nonsense without thinking any longer about it.

That's OK, it's been a perfectly civilised debate after all. You're making a fair point insisting on a distinction between implementations and the spec. My initial posts were very unclear in that regard.

I'm talking about every single Java language implementation that I know of. And I believe (although I'm not completely sure) that the Java language specification requires it at least implicitly.

https://github.com/kilim/kilim

Reply on news.ycombinator.com