Java at 30: Interview with James Gosling

Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby.

Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine.

Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff.

What do you get for all of these tradeoffs? Speed, memory safety. But with that you still still have dynamic invocation capabilities (making things like interception possible) and hotswap/live redefinition (things that C/CPP cannot do).

Perfect? No, but very practical for the real world use case.

> And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc),

Java's tools are really top notch. Using IntelliJ for Java feels a whole new different world from using IDEs for other languages.

Speaking of Go, does anyone know why Go community is not hot on developing containers for concurrent data structures? I see Mutex this and lock that scattering in Go code, while in Java community the #1 advice on writing concurrency code is to use Java's amazing containers. Sometimes, I do miss the java.util.concurrent and JCTools.

Just implement concurrency with actors and u save up on some locks and mutexes...

The patterns are available, its up to the community to apply proper concurrency patterns.

Actors are implemented using locks.

Is it really so? I haven't checked all the implementations, but my take here would be to use a channel with atomics instead of a lock...

It's probably possible to do if you think about it carefully but generally enqueuing a message is going to take a lock, especially if you can send an arbitrary number of messages (which may require the queue to be reallocated).