Hacker News Reader

Comment by diakritikal | Hacker News Reader

Oracle are their own worst problem right now.

My managing director dictated Libre Office over Open Office because it solves his problems with OO.

My dev team are keen as mustard to replace the remaining MySQL instances with MariaDB. Supporting an opaque platform that in turn is not likely to be supported by the distro's we use is not an appealing proposition.

Oracle respin of Red Hat was never an appealing option. We're a SUSE crowd at heart anyway.

From Oracles offerings (the ones they bought, we'll never use oracle DB) that leaves Java as a language and tool set. Dev time is too costly, the language is too clunky, the memory pressure is too high.

View on HN

Quite agreed.

Oracle's association with pretty much any product (free software or otherwise) is enough for me to head in the other direction, and those are the recommendations I pass on to my clients, employers, and/or others asking for recommendations.

Happily, from Oracle's perspective, their legal win in their case against Google will not doubt quickly be leveraged to kill off the MySQL forks for copying MySQL's copyrighted APIs.

No. The APIs are covered by the GPL just as the implementation.

Likewise for Java.

Correct me if I'm wrong, but I think if Dalvik were released under a license compatible with the Oracle runtimes, this whole thing between Oracle and Google goes away? I agree allowing copyrighting of APIs is a bit daft, but the point is that if you're trying to draw a parallel between MySQL/MariaDB and Java/Dalvik, it doesn't apply. (Assuming the MariaDB fork has a compatible license, which I believe it does.)

> ... that leaves Java as a language and tool set. Dev time is too costly, the language is too clunky, the memory pressure is too high.

Are there languages out there with lower memory pressure that cost less in dev time?

You will doubtlessly get many opinions on this.

It's worth keeping in mind that the "dev time" is a function of existing libraries, internal and external. At any fairly large company (e.g. Google) that has many existing internal libraries in some language (java), the dev time will be massive to switch. By this logic, the dev time is too costly for absolutely any language you pick other than the one being used. There is little exception to this.

For a programmer or programmers with no legacy cruft, I'd argue that dev time is more a function of the programmer's familiarity with a language than the language itself. Perhaps there are a few exceptions to that, but in general I don't think that a language should be described as "too" anything. Java might be memory inefficient, but does that mean it's usage "too high"? Clearly not for some people as it's still used frequently.

Isn't Go's purpose to be a high-performance language that improves worker productivity?

Relative to what other languages, though? The competition gives important context.

I can say, "Language X is designed to be fast". But that doesn't tell you what it is good for.

What if I say "Language X is designed to be faster than Python"? Doesn't that tell you way more about Language X?

Reply on news.ycombinator.com