Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

661–670 of 679 posts

Re: Go is Google's language, not ours

#661
post #657
post #558

Earlier quoted context omitted.

> because it made sense even back then. That was necessary for performance back then. User-defined value types weren't, and Java has done well without them. > Object has semantics, and that was a mistake, because it contributes to the bloat. I think most of the RAM bloat is due to the GC trading off extra RAM for speed rather than object headers, and I'm not sure trading off complexity for headers was right 25 years…

Heap (over)use by the GC is effectively a scaling factor. How large the underlying objects are remains remains relevant: if your objects are twice the size necessary, the GC will "bloat" that further - and this tradeoff isn't entirely GC specific, other allocators such as those used to implement malloc/free have related tradeoffs to make; free() won't release memory to the OS either (and memory, released or not, may…

Of course it is relevant. I'm just saying it isn't the decisive factor that makes this an absolute necessity, as evidenced by the fact that much the backbone of the largest software services in the world is Java. There are lots and lots of tradeoffs in runtime design, and it's important to look at the whole rather than at one decision in isolation and point out that it's important. As a whole, the criticality of value types for Java is relatively recent.

Re: Go is Google's language, not ours

#662
post #643
post #642

Earlier quoted context omitted.

What user-defined value types did CL have in '95? Also, are you sure about VB having had them then? As for AOT, there may not have been sufficient demand from Sun/Oracle. I only joined relatively recently, but we generally do expensive things only if we believe they have a huge benefit or in huge demand, and we believe it can be long-lasting. The assumption is that any new feature will require maintenance for 20 year…

Arrays, structs, fixnums, explicit stack allocation. I can check the respective manuals if you wish. Yep, I did VB programming for a short while. And please note that even though my focus is now elsewhere, Java is one of my favourite eco-systems. As a peasant I just wished that Java 1.0 was more like Go, given the existing alternatives back then. So it kind of stayed as a pet peeve of mine. Same applies to .NET, just…

Well, we can disagree about when AOT and value types became critical for Java (and I would argue that they clearly weren't back then because Java has done spectacularly without them), but Java is getting both soon.

Re: Go is Google's language, not ours

#663
post #662
post #643

Earlier quoted context omitted.

Arrays, structs, fixnums, explicit stack allocation. I can check the respective manuals if you wish. Yep, I did VB programming for a short while. And please note that even though my focus is now elsewhere, Java is one of my favourite eco-systems. As a peasant I just wished that Java 1.0 was more like Go, given the existing alternatives back then. So it kind of stayed as a pet peeve of mine. Same applies to .NET, just…

Well, we can disagree about when AOT and value types became critical for Java (and I would argue that they clearly weren't back then because Java has done spectacularly without them), but Java is getting both soon.

I would say that it had other factors that contributed to its sucess, so it succeeded in spite of lacking those features.

However due to the hardware architecture changes and new kids on the block, it is starting to be an issue.

I keep wishing to see them arrive, have watched all the JVM Language Summit, Devoxx and JavaONE talks about them.

Meanwhile I can already enjoy them elsewhere. :(

Re: Go is Google's language, not ours

#664
post #663
post #662

Earlier quoted context omitted.

Well, we can disagree about when AOT and value types became critical for Java (and I would argue that they clearly weren't back then because Java has done spectacularly without them), but Java is getting both soon.

I would say that it had other factors that contributed to its sucess, so it succeeded in spite of lacking those features. However due to the hardware architecture changes and new kids on the block, it is starting to be an issue. I keep wishing to see them arrive, have watched all the JVM Language Summit, Devoxx and JavaONE talks about them. Meanwhile I can already enjoy them elsewhere. :(

> Meanwhile I can already enjoy them elsewhere. :(

That's perfectly fine. We think that our priorities are right for the workloads Java is used for (e.g. people care more about a low-latency GC like ZGC, and deep low-overhead in-production profiling, like JFR, than about AOT).

Re: Go is Google's language, not ours

#665
post #655
post #628

Earlier quoted context omitted.

The fact is Go team learns from other implementations and it's clear from talks and articles. Another fact is that you're accusing them in having the "mindset of refusing to look at established work". Those two facts don't get along together, that's why I disagree.

They stuck their heads in the sand refusing to have a package manager for like 8 years and asking people to put dependencies on a vendor folder. That's not learning from established work.

because implementing package manager well is not a trivial work. I had no problems with vendor (godep), later I used Dep and now modules. There are still some problems with module handling for vscode (gopls) but that will be sorted out over time. If you don't like the way Go is going, what stops you from using Java with maven, gradle or whatever...

Re: Go is Google's language, not ours

#666

Earlier quoted context omitted.

Are they paying Oracle though? A quick Google found this: https://seekingalpha.com/article/4229086-oracle-growth-dead If Oracle revenue is no longer growing, maybe new development leans more towards Postgres and other open source offerings?

> Revenue US$39.83 billion (2018) Even not growing, they are indeed paying Oracle.

Isn't that mainly for integrations though? I would think straight Oracle RDBMS licensing would be on life support without some big ERP connector etc.

Re: Go is Google's language, not ours

#668
post #24

Actually there are relatively few real (TM) open source projects driven by the community, at least if you look at important projects. Many open source projects are just commercial projects driven mainly by a single company. Look for example at Redis, MongoDB, MySQL, and Elasticsearch. They follow exactly the model described in the article. Technologies like these could have been developed by a community, too, but it…

The simple and sad truth: -Nobody gets fired for buying Oracle. -It's easy .. explaining an investment in open source .. good luck

> Nobody gets fired for buying Oracle

I can think of environments where you'd get fired. Oracle these days screams "legacy", and especially if you're working on low-latency projects like trading systems it would be a huge, expensive mistake.

Re: Go is Google's language, not ours

#669
post #24

Actually there are relatively few real (TM) open source projects driven by the community, at least if you look at important projects. Many open source projects are just commercial projects driven mainly by a single company. Look for example at Redis, MongoDB, MySQL, and Elasticsearch. They follow exactly the model described in the article. Technologies like these could have been developed by a community, too, but it…

The simple and sad truth: -Nobody gets fired for buying Oracle. -It's easy .. explaining an investment in open source .. good luck

> Nobody gets fired for buying Oracle.

Nah, even when Oracle was more dominant than they are today, that wasn't entirely true:

https://www.cnet.com/news/california-cancels-oracle-contract...

Re: Go is Google's language, not ours

#670
post #620

Earlier quoted context omitted.

These are not bad things if you’re writing system code.

Is there ever a plan for GC?

There are garbage collection libraries in progress: rust-gc[1] and shifgrethor[2]. If you mean language support, then no, not really, though it was discussed in https://github.com/rust-lang/rfcs/issues/415

[1]: https://github.com/Manishearth/rust-gc [2]: https://github.com/withoutboats/shifgrethor

Post reply on HN