> My advice is to look into things like Scala ... +1. I think one of the main differences the OP will enjoy is that Scala allows abstraction without the heavy indirection penalty Java forces upon you. There is tons of…
> So your post is meaningless and useless. Can I hand you some tissue so that you can get rid of your angry tears? That Go reality distortion field seems to be strong. > 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…
> The lack of half-decent theming in Eclipse and > Preferences/Settings being all over the place > really puts me off ScalaIDE personally. Agree. I can recommend http://eclipsecolorthemes.org/ combined with…
* 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.…
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…
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…
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…
> 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. That makes Go look even worse, doesn't it?
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?
> My advice is to look into things like Scala ... +1. I think one of the main differences the OP will enjoy is that Scala allows abstraction without the heavy indirection penalty Java forces upon you. There is tons of…
> So your post is meaningless and useless. Can I hand you some tissue so that you can get rid of your angry tears? That Go reality distortion field seems to be strong. > 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…
> The lack of half-decent theming in Eclipse and > Preferences/Settings being all over the place > really puts me off ScalaIDE personally. Agree. I can recommend http://eclipsecolorthemes.org/ combined with…
* 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.…
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…
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…
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…
> 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. That makes Go look even worse, doesn't it?
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?