HN user
> So your post is meaningless and useless.
> why didn't you simply point out the flaws?
Yet another Go fanboy getting a bit defensive without having to add anything constructive?
If you actually checked your “claims” you would see that people are singing so many praises that the mailing list is continually filled with proposals to fix the worst parts of Go's packaging system.
> The lack of half-decent theming in Eclipse and
> Preferences/Settings being all over the place
> really puts me off ScalaIDE personally.
* Their implementation sucks so much that most decently built
concurrency implementation will beat Go-routines by a wide
margin. Just have a look at all those people on the Go mailing
list whining about the scheduler. Not even talking about the
fact that building concurrency mechanisms into the language is
plain stupid. We all saw how well that worked out in plenty of
other languages before.
* You know why pretty much no one uses structural typing?
It's not because the “brilliant” designers of Go “invented” it,
it's because most language designers realized that it is a poor
idea before shipping the language. I think it is pretty telling
that in languages which support both nominal and structural
typing pretty much nobody is using structural typing.
* I'm not seeing how a language which requires passing around
void* pointers in every data-structure and casting at pretty
much every corner can be considered memory efficient.
* Hard-coding collection classes with special cased syntax into
the language, so that everyone who needs to have something
slightly different is completely fucked ... what is this? 1980?
* Their packaging system is an unmitigated failure. Nuff' said.
* Do they have a working Unicode implementation yet (I mean more
than the “We use UTF8 for strings ... which is like 0.5% of
what Unicode is about”)? What about (Big)Decimal? A working
date/calendar abstraction which isn't a terrible joke?Did you ever actually use Go for a few minutes? Most of these bullet points are plain wrong.
Sort is just one instance where one can work around Go's limitations, this is not repeatable in general.
I think Google already had a lot fun with Oracle while not using their code.
If you fork, be prepared for a patent-infringement lawsuit as soon as you earn some money with it.
I'm pretty sure most companies have realized that staying the hell away from Oracle isn't a stupid move.
The problem is that nobody trusts Oracle. Have a look at what happened to Google. Their code didn't even originate from Oracle and they still got sued for made-up, bullshit reasons.
It of course sucks for those who invested their time in hacking the Oracle stack, but I think many people these days outside the Oracle bubble see Oracle as a dead-end.
Most people don't have a war chest full of money to hire the best lawyers like Google to protect them against baseless lawsuits.
Anyway, even from a technical point of view, things like Graal and Truffle are terrible workarounds and I prefer just fixing the things which are broken in the first place. Seeing that this will never happen at Oracle, I'll just work on code were the maintainer/owners are not so openly hostile.
I think the key point you are missing is developer productivity.
Every potential performance gain C++ might have is completely negated by having to touch that complete clusterfuck of a language.
Yes. The first slide basically guaranteed that I will never look into this project.
The risk of touching anything Oracle-related is not worth the potential benefit.
Wrong, wrong, wrong and wrong.
It uses exactly as much memory as you specify. It would be pretty stupid to have plenty of RAM and NOT using it. With enough memory GC becomes essentially free, by not having to do any work.
It has gotten a lot better on all fronts.
Me too. This and all those Go fanboys make me really embarrassed of my profession.
This blog post is extremely vague and handwavy.
Looking into the actual source code didn't reveal anything “special” either, so I'll just call bullshit on these claims.
Feel free to prove me wrong.
That's my impression too. The lone sysadmin who has to hack something up and moves on to other work likes Go; real developers who work in teams and have to maintain their codebase a month down the road stay the hell away from it.
> So, your comparison here is not fair. You should compare
> Go's package management with Python plus
> setuptools/easy_install, Java plus Maven, Haskell plus
> Cabal, etc.
OO subtyping is hard to reason about formally in formal systems _in general_.
Eh... what exactly is "lightweight" about your threads?
As far as I see you still use the same, standard JVM threads everyone uses, combined with a thread pool.
What am I missing?