dubbledidu

  > So your post is meaningless and useless.

  > why didn't you simply point out the flaws?

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?

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.

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.

Every potential performance gain C++ might have is completely negated by having to touch that complete clusterfuck of a language.

The risk of touching anything Oracle-related is not worth the potential benefit.

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.

  > 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.

As far as I see you still use the same, standard JVM threads everyone uses, combined with a thread pool.

What am I missing?