The difference is that JVM community welcomes languages PhD folks.
There is even the JVM Languages Summit.
Unthinkable in Go ecosystem.
There is even the JVM Languages Summit.
Unthinkable in Go ecosystem.
Or that Robert Griesemer literally is a language PhD, whose thesis was supervised by a little fellow by the name of “Niklaus Wirth”?
https://www.research-collection.ethz.ch/handle/20.500.11850/...
“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”
-- Rob Pike
Sounds pretty damning, I'd say. This of course illustrates why Go is called "systems PHP".
> how much one was willing to pay for a commercial JDK.
I strongly prefer open-source tools at the base of my stack. Not as much because of the money but more because of the level of trust. Things should be inspectable.
- .Net devs (they are almost as annoying as us Java/Kotlin devs)
- a language and ecosystem that consistently sacrifice backwards compatibility (contrary to us who have features sacrificed for backwards compatibility at every single step)
- you have to live without the JVM ecosystem (on this I have no self deprecating comment, C# is a better language, but the ecosystem, from libraries to build system to IDEs is something I always miss when I work in .Net.)
.NET maintains excellent backwards compatibility, C# and F# even more so. The changes either affect frameworks and libraries, which you can often update independently or are easily addressed. Most projects since .NET 5 only ever had to bump the target version and rebuild to move forward (notable exception: in .NET 6 ASP.NET Core introduced simplified API for application setup which required changes).
Neither JVM nor Go have the degree of low-level capabilities .NET provides first-class support for. And F# integrates in an easier way into existing C# solutions than Kotlin does into Java ones.
It is the GC-based Rust alternative many are looking for but are overlooking due to bias from the past.
It is my feeling that .Net developers with some years of experience get wide eyed when I tell them how I can use any old library that I need together with the newest JVM and my platform upgrades have mostly consisted of bumping numbers.
It's nothing surprising in .NET land. If you target netstandard2.0 the library will work on any version from .NET Framework 4.6.1 and upwards. For many newer features there are compat and polyfill pacakges too - that's one of the strengths to be able to use them even on the older targets.
All newer targets are forward compatible anyway. Wherever the notion of otherwise comes from it is likely a misunderstanding or trolling.
You can't make a serious argument when comparing baseline experience where .NET confidently places next to Cargo and Golang's user experience with the level of productivity it provides for setting up and managing projects and dependencies, building them and distributing them. JVM ecosystem still does not offer capability to properly and easily package the applications into a single binary except using very restrictive GraalVMs Native Image which does not have as wide ecosystem support as NativeAOT enjoys, and where it does not work .NET still gives you the ability to bundle managed assemblies into an executable together with runtime, apply trimming and get relatively compact result.
I think you should read up on the guidelines before abusing the flagging system as a way to punish someone you disagree with.
Anyway, I am out of here.
Yes there are AOT friendly frameworks, however JVM agents have also provided a way to gather the necessary data for a AOT compilation, since the Exelcisor JET days.
Including Microsoft own products.
So I would slow down on the whole Java versus .NET flamewars, regarding who's more competent.
I use both ecosystems, because both have plus and minus, and complement themselves.
Is this what is so damning about Go? The constant reposting of this quote as some sort of attack on Go's validity and reputation reeks of nothing but classism.
"incapable" != "never capable", especially when talking about fresh college graduates.
“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”
-- Rob Pike
That's just not what he said or implied.
It's not a perfect language, but it's a pretty good language for building shit and shipping stuff.
And it starts getting to you, because a lot of problems just don't have nice solutions in the language because of its limitations. So you start accumulating kludges, which lowers the bar for quality in the entire code base.
There are PLENTY of techniques and abstractions that are VERY useful yet not expressible in a sane way in Go.
It's a nice enough language for beginners, but acting like it's the end all of programming just makes you look like a fool.
Mr. Pike's quotation assumes that the Googlers should not be expected to be too intellectually capable. That's the damning part for me.
The fact that none of these highly accomplished individuals want anything FP-related in Go says far more than what typical Go-haters want to think it does.
Does it?
I'm not a Go hater but just because they were involved in making the things you listed doesn't mean they would do it again with Go. It just means they don't trust others with different languages.
I don't think what you said refutes people's perception of Go, which is its a fairly limited language that is good for keeping people on rails (like fresh grads). That might make sense for a large business hiring lots of people but maybe not for small companies.
Also there is a world of difference between FP features and the basic features people asked for in Go (like generics).