Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'll repeat this until my karma is zero: Erlang, Rust and Go have simple memory models and cannot do Joint (on the same memory) Parallelism efficiently.

They are only fragmenting development.

In my opinion there are only two programming languages worth mastering: C+ (C syntax compiled with cl/g++) on client and Java SE (8u181) on server. That said C++ (namespaces/string/stream) and JavaScript (HTML5) can be useful for client/web.

All other languages are completely garbage! Not only do they have huge opportunity cost, but they make it harder for this civilization to be useful long term!

We have linux/windows and C/Java, instead of making another language in C, make something useful that is open-source instead!

Edit: Most downvoters here will be technology naive; they think everything gets better for eternity, but in reality everything hits it's peak at some point and electron processors and their OS/languages have now explored all viable avenues. Accept that and stop wasting time!



There is a reason why people are moving away from shared memory parallelism.

It's not fun to deal with NUMA domains efficiently. For hardware engineers, it's not fun implementing cache coherency protocol efficiently.

There is a reason why even Intel was experimenting with channels back in 2010 and you see more and more "network on chip", "cluster on chip" designs with non cache coherent memory.

As we need more cores, shared-memory synchronization becomes too costly.

Source:

- https://en.wikipedia.org/wiki/Single-chip_Cloud_Computer

PS: I'm not even talking about the difficulty of writing correct concurrent data structures.

Even glibc authors get that wrong https://news.ycombinator.com/item?id=26385761


Are atomics and shared-memory lock-free data structures dying, and will they be replaced with channels at the hardware level? Or can atomics still be implemented on top of NUMA, or even not-really-shared-memory processors?


Yes, it's hard, but it's the only way forward.


I don't think you read my comment properly. I'm saying that shared memory parallelism has done its time even at the hardware level within a CPU.

Most programming languages are using construct that assume memory coherency for synchronization (like atomics). It may very well be that hardware channels and DMA become more prevalent in the future as more and more cores are packed and shared memory becomes prohibitive. This would be a totally different paradigm.


Well I don't know the details, but if you read my comment below you'll see that there might be a good reason to use a complex memory model VM with GC.

I can't explain it, just claim that my code works and performs accordingly: https://github.com/tinspin/rupy


Why Java 8 as opposed to the latest JDK?

And what about C#? It's in a similar boat as Java.

Also, how is the Java memory model different from Go for this use case? They both allow mutation by sharing.


Java 8 is the last free Oracle JDK, nothing added after 8 is really interesting enough to take the complexity hit that Java 9/10/11 etc. mean.

I'm waiting for user space network, that is the last feature that will make the switch worth: my system uses almost as much kernel copy CPU as my user space process!!!

C# is an ok alternative but they went for value types instead of sticking to the VM. Java has atleast 10 years head start on C#, also Microsoft.

Go has no VM but uses GC, thay miss half of the requirements to make Joint Parallelism!

WebAssembly has a VM but no GC, that is more interesting, unfortunately there is no glue code in the reference implementations!


> Java 8 is the last free Oracle JDK, nothing added after 8 is really interesting enough to take the complexity hit that Java 9/10/11 etc. mean.

The low latency GCs and the general performance improvements seem quite good though.

> C# is an ok alternative but they went for value types

Java is also getting value types (project Valhalla).

> Go has no VM but uses GC, thay miss half of the requirements to make Joint Parallelism!

What do you mean by Joint Parallelism? I didn't find relevant resources. And is it bound to having a VM?


Well, there was a real-time thing bought by Sun from Sweden but I'm still unclear as to how much of that has made it into the open-source part of the JDK. Time will tell!

Joint Parallelism is a term that I invented, it means loosely defined: if two threads can read and write to the same memory at the same time without it causing too much loss... basically you need atomic concurrency which is only really efficient on a complex memory model VM with GC if you want high level language support:

"While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html

"Many lock-free structures offer atomic-free read paths, notably concurrent containers in garbage collected languages, such as ConcurrentHashMap in Java. Languages without garbage collection have fewer straightforward options, mostly because safe memory reclamation is a hard problem..." - Travis Downs https://travisdowns.github.io/blog/2020/07/06/concurrency-co...

I'm not an expert, I can't explain why these things are true, because I'm trying to make something useful on top of C/Java instead of going too deep.

But what I do know is that my app. server kicks everythings ass to the stone age in terms of performance and ease of use: https://github.com/tinspin/rupy

It's facinating to see humans struggle with the wrong tools, and defending those same tools without even trying the alternatives (I have also worked with perl, PHP and C# so I know why those are bad).

But I'm sure time will flush the bad apples out eventually, specially when electricity prices go up.


The low latency GCs I'm referring to are ZGC and Shenandoah, both of which are in the JDK:

* https://openjdk.java.net/projects/zgc/

* https://openjdk.java.net/projects/shenandoah/

Thank you for the rest of the post, it's very insightful :)


While you were chasing girls I was in my basement mastering java (SE 8u181)


Humans waste billions of hours and dollars in casinos - apply your efforts here and you’ll help the human race much more.


This is just plain wrong. There's nothing you can do in C/C++ (or C+, as you put it) that you can't in rust, when it comes to parallelism. There's always unsafe if you really need it.


Can you give an example that C+ can do efficiently that Rust cannot do efficiently even with ‘unsafe’?




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

Search: