What is amazing to me is that Java could attract such a huge community, so much so that top talents could produce an amazing array of libraries, frameworks, and systems. The ecosystem of Java simply makes lots of daily work really easy. And no, I've never used Spring or Hibernate or those "enterprise" frameworks. That said, many enterprise software engineers, or so I heard, do like the productivity brought forth by Spring. Frankly, I don't understand why people keep mentioning Spring as if it's the culprit of Java. Spring is just one of the huge number of choices in Java's ecosystems. To me, Java offered great productivity tools at the right time over the years. Let's not even talk about communities or successful systems. Just a few seemingly small things:
1. IDE. When Eclipse was released back in the early 2000's, it was an amazingly productive tool. Refactoring is a one or two keystrokes away. Java's simple yet mostly sufficient type system allows us to jump around definitions, references, usages, and declarations easily. The built-in compiler of Eclipse allows really accurate auto completions. I could easily learn a new code base by walking through the code with a debugger while jumping around the source code by semantics.
2. Standards. First its servlet, but soon web containers. Even in its early days, such standard made it much easier to write web applications. Engineers just needed to remember a few simple rules before producing concurrent web services.
3. JVM and all the toolchains. All the jconsole, jstack, jmap, gc logs, etc and etc. They may be norm now, but when they were productivity boosters when they first came out.
4. Java's standard libraries, especially the concurrency libraries. All those containers and high-level synchronizers are so much easier than the vanila mutex. This is something I don't quite understand about the Go community: why are people fine with using Mutex everywhere?
5. All kinds of JSRs, such as JAX-RS. You may hate them personally and passionately, but they do provide easy enough APIs and most importantly a standard for all kinds of frameworks to support. A Java programmer can easily switch from one framework to another without much learning curve.
> 1. IDE. When Eclipse was released back in the early 2000's, it was an amazingly productive tool. Refactoring is a one or two keystrokes away. Java's simple yet mostly sufficient type system allows us to jump around definitions, references, usages, and declarations easily. The built-in compiler of Eclipse allows really accurate auto completions. I could easily learn a new code base by walk the code through a debugger while jumping around the source code by semantics.
I wonder how much Java success in early 2000's was related exclusive to this. I remember asking Java programmers why they liked it so much and all they talked was about IDE features and not the language itself. It looked like some couldn't even tell the difference between an IDE and a programming language.
Even before Eclipse, there were some free (but not open) versions of commercial IDEs such as Borland JBuilder. JBuilder in particular was truly incredible in terms of features for the late 90s-early 00s, also considering it ran well on just 128 MB RAM.
> What is amazing to me is that Java could attract such a huge community
Why is it amazing? Java was a well-compromised piece of PLT design, by a geek friendly company known for its engineering chops, with a very cool (hackable!) VM that allowed for both compiletime and runtime magic, and all this over and above the fairly well equipped standard library. (Beyond that, concerted Java hype in late 90s was ~same as what we saw later with RoR, Scala, Go, and now apparently Rust. Java may not be cool these days but it was the shiny thing in late 90s.)
>This is something I don't quite understand about the Go community: why are people fine with using Mutex everywhere?
The default approach in Go is to use channels. The preferred idiom is "share by communicating". I think mutexes are overused by people who came from other languages and who aren't accustomed to channels yet. They spawn goroutines which communicate by sharing when it should be the other away around - no shared state with a few exceptions. I think there's no proliferation of synchronization primitives in Go because sharing state is considered a bad practice.
Got it. I saw ReMutex used on maps, for instance, the other day. What if one needs to have shared data, say, a routing table for all incoming requests?
>This is something I don't quite understand about the Go community: why do people are fine with using Mutex everywhere?
While I wouldn't say I never used Mutex in my life, pretty much all the nice high-level parallelism primities, such as map-reduce, event loop-based workers, signals, cancellation can be emulated pretty well with channels - using Mutex is pretty much never necessary in day-to-day Go programming.
1. IDE. When Eclipse was released back in the early 2000's, it was an amazingly productive tool. Refactoring is a one or two keystrokes away. Java's simple yet mostly sufficient type system allows us to jump around definitions, references, usages, and declarations easily. The built-in compiler of Eclipse allows really accurate auto completions. I could easily learn a new code base by walking through the code with a debugger while jumping around the source code by semantics.
2. Standards. First its servlet, but soon web containers. Even in its early days, such standard made it much easier to write web applications. Engineers just needed to remember a few simple rules before producing concurrent web services.
3. JVM and all the toolchains. All the jconsole, jstack, jmap, gc logs, etc and etc. They may be norm now, but when they were productivity boosters when they first came out.
4. Java's standard libraries, especially the concurrency libraries. All those containers and high-level synchronizers are so much easier than the vanila mutex. This is something I don't quite understand about the Go community: why are people fine with using Mutex everywhere?
5. All kinds of JSRs, such as JAX-RS. You may hate them personally and passionately, but they do provide easy enough APIs and most importantly a standard for all kinds of frameworks to support. A Java programmer can easily switch from one framework to another without much learning curve.