* 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?
Take his criticism (not sure it even merits that title) with a grain of salt. Many people on HN and on the mailing list have sung the praises of Go's packaging system.
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.
Your post has no substance, other than to say some people on the mailing list don't like it. But other people on the mailing list do like it. So your post is meaningless and useless.
If you actually have problems with Go's packaging, and care about it enough to write as much as you have, why didn't you simply point out the flaws?
> Because there are already dozens of people who did that already?
Do you really expect people to scour a newsgroup to find the meaning of your vague and unsubstantiated claims?
Someone could similarly say "Scala is an unmitigated failure of a language. If you want to know why, just track down its detractors on the Internet. There are dozens." Would you be impressed by that?
Actually, most companies that aren't Google (finance, government, military, enterprise) realized that simply sticking with Oracle is even a better move. I don't know if you know this, but Oracle is making more money (profit) than Google (Oracle is also a much larger company than Google). They wouldn't be doing that if people were staying away from them. Lawsuit aside, even Google itself (and Facebook, and Twitter) runs most/much of its software on Oracle technology, so I guess they're doing something right. It's just that HN is skewed in favor of smaller-scale software. When you're in the major league, Java is often the only smart option.
there may be more reasons other than technical that large businesses run on Oracle (database).
The amount of paid "consultants" that oracle pushes thru to make their sale, plus their tactic of charging what you can afford to pay, as well as the "can't get fired for buying IBM" mentality of large IT organizations means that oracle has a distinct advantage over any small competitor.
Not that oracle's tech isn't good, but there are comparable alternatives, but they are only comparable in the technical aspect, not in the (strongarm) sales aspect.
.NET is a fine alternative in 80% of the use cases. Honestly, in half of the projects I see coming through, the only reason java is a requirement is because everything else is already in java; the only hang up is DB2/MSSQL/Oracle drivers.
.NET is never a good option to Java. The CLR suffers the same performance issues as the JVM and as noted in the thread above people are starting to migrate back to C++ as a result and yet .NET has the further restriction that it only runs on Microsoft systems. So with .NET I get the disadvantages of Java combined with the restriction of not being to migrate to other platforms. That's not a good deal for the enterprise.
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.
But you see, this is exactly the wrong kind of conversation. You can't say "nobody trusts Oracle" while Oracle is bigger and more profitable than Google, and while the majority of important software worldwide is built on Oracle technology. Oracle won't pay attention to this kind of statement because it's obviously false. The truth is that most companies do trust Oracle.
What we can and should say is that Oracle is losing the trust of the Silicon Valley startup crows, and that this is a very important population segment. It's like a candidate being elected but gradually losing the young vote – it's a bad sign that Oracle would do well to consider.
In the really large server-side systems we're talking about here (banks, defense, etc.) both developer productivity and maximum speed rank way, way below other factors, such as having long-lived processes.
Java's not a clusterfuck? I'll take the clusterfuck that's not controlled by a creepy asshole who thinks the NSA is essential and says stupid shit like "Who's ever heard of government misusing information?"
After hearing how Solaris support when down the drain with Oracle stewardship, I'd say staying away from anything Oracle sounds reasonable. At least if it isn't under something like GPL with a patent grant.
(Yes, the fact that they screwed minor Solaris customers does not translate to them suing over IP -- but then again, they already did the last part to).
Oracle is probably a great company to invest in; they make a lot of money -- but that alone doesn't make them a good stakeholder in your core business. I wouldn't want to partner with McDonalds either.
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.
Nonsense. I'm talking about the SAME data taking more memory to represent. Plus, all things being equal a larger memory space will take more time to GC, and GCs become longer, not shorter.
The JVM does things suboptimally in a number of ways. Object memory overhead is relatively high - typically 8 or 16 bytes per object, strings as UTF-16 (vs Go's UTF-8), etc. It really adds up, and funtional languages tend to churn lots of GC.
This is the first time I ever heard anybody complain about UTF-16, citing it as the reason for why the JVM consumes more memory, which is of course bullshit.
One reason for why JVM apps appear to consume so much memory is because the JVM allocates more memory than it needs. It does so because the garbage collectors are generational and compacting (well, CMS is non-compacting, but when the memory gets too fragmented, the VM does fallback to a stop-the-world compaction of memory). In a server context the JVM also does not release the free memory it has to the operating system, because allocating that memory in the first place is expensive and so it keeps it for later usage ... the result is that memory allocation on top of the JVM is as efficient as stack allocation, since all the JVM does is to increment a pointer, and deallocation of short-lived objects is nearly as innexpensive as stack unwinding, since the GC is generational and deallocates stuff in bulk. These capabilities come at a cost, as the GC also needs memory to move things around, but it's also memory well spent (e.g. Firefox has been plagued by memory fragmentation for years).
Speaking of Golang, it has some of the shittiest GCs in existence ... non-generational, non-compacting, non-concurrent and "mostly precise". Of course, it used to be fully conservative, which meant you could easily end up with really nasty memory leaks on 32bits systems, because the GC wasn't able to make a difference between Ints and pointers.
The only thing saving Go is the ability to work in many cases with the stack, alleviating the stress that the GC faces, but this low-level capability will also prevent it from having a good GC anytime soon, like the JVM has had for years.
And really, in terms of memory usage, you should see how the JVM's CMS or G1 behaves in production, as it makes all the difference. Our web-service (written in Scala) that's being hit by more than 30,000 requests per second that must be served in under 100ms per request, was at some point hosted on Heroku, using only 8 instances, instances which have less than 400 MB of usable RAM. It was absolutely superb seeing it in action, as the processes themselves were not exceeding 200 MB of real usage - Heroku even told us that we are costing them more than we are paying them.
So yeah, you can talk bullshit about strings being UTF-16, but the real wold disagrees.
