←back to thread

Java at 30: Interview with James Gosling

(thenewstack.io)
193 points chhum | 1 comments | 16 May 25 13:05 UTC | HN request time: 0.204s | source
Show context
exabrial ◴[16 May 25 14:51 UTC] No.44006194[source]▶
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.

replies(15): >>44006269 #>>44006358 #>>44006411 #>>44006567 #>>44006570 #>>44006865 #>>44007100 #>>44007464 #>>44007662 #>>44007666 #>>44009121 #>>44009861 #>>44011219 #>>44011642 #>>44012473 #
hintymad ◴[16 May 25 19:43 UTC] No.44009121[source]▶
> 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.

replies(3): >>44009525 #>>44009597 #>>44011488 #
1. shanemhansen ◴[17 May 25 02:02 UTC] No.44011488[source]▶
I'll offer a counterpoint to the responses. Until go got generics, concurrent data structures were awkward. The stdlib now does include things like sync.Map.

In fact my experience has been that overuse of channels is a code smell that alot of new go developers fall into and later regret. There's a reason the log package uses a mutex for synchronization.

In general I think channels are great for connecting a few large chunks of your program together. Concurrency is great but also not every function call benefits from being turned into a distributed system.

I think that it would be a great idea to develop more concurrent go data structures with generics and I suspect inertia is what's keeping the community from doing it.

My credentials such as the are: been writing go since 1.0. worked at Google and taught go classes as well as owned some of the original go services (the downloads server aka payload server).