Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

261–270 of 679 posts

Re: Go is Google's language, not ours

#261
post #245
post #218

Earlier quoted context omitted.

You can opt out of using those extensions in your own code, but many of them are now deeply embedded in the library ecosystem.

Indeed. It's like a feature democracy where each library gets a vote on which features it finds most useful. Those that then get deeply embedded are clearly those that are most useful. Those features that aren't particularly used don't really get anywhere.

I sort of agree with that, but features often have externalities. For example, let's say I choose to use lambda case because it makes some of my code a little bit more concise. From my narrow point of view, that seems like a win. But then it's one more piece of syntax that external tools have to deal with, one more barrier to anyone trying to develop an alternative to GHC, one little piece of additional complexity to throw off Haskell newbies who want to read my code, etc. etc.

Re: Go is Google's language, not ours

#262

Earlier quoted context omitted.

Modern Java is a pleasant experience compared to Go.

Can you elaborate? In what ways, is modern Java a more pleasant experience compared to Go?

Look at what happened to Kubernetes. They rewrote original Java code in Go and it's a mess because of Go's limited abstraction capabilities. Sure there's an element of rewriting in a new language and attempts to force idioms, but there's also the fact that Go literally hacks in special cases for generics, unavailable to users. They recognize the need for generics, but haven't implemented them, which is a problem for a complex project where abstraction might be useful.

Re: Go is Google's language, not ours

#263

I'm going to risk being labeled an ~incompetent dev~ or whatever but learning golang was seriously a breath of fresh air compared to literally any language I have ever tried to grok before. Everything felt like it was there on purpose. It always seemed like there was a "proper" way to achieve something. Being told to use this opinionated formatter was like removing a 40kg bag after a bush walk. You never have to worr…

> Being told to use this opinionated formatter was like removing a 40kg bag after a bush walk.

This is how I feel about prettier.

> The last thing I personally want to see is Go being handed over to the community to be designed by committee.

I feel this way about many projects. You can’t beat good stewardship/vision, and sometimes it’s corpotate.

Re: Go is Google's language, not ours

#266
post #262

Earlier quoted context omitted.

Can you elaborate? In what ways, is modern Java a more pleasant experience compared to Go?

Look at what happened to Kubernetes. They rewrote original Java code in Go and it's a mess because of Go's limited abstraction capabilities. Sure there's an element of rewriting in a new language and attempts to force idioms, but there's also the fact that Go literally hacks in special cases for generics, unavailable to users. They recognize the need for generics, but haven't implemented them, which is a problem for…

If Graal had been mature at the time, I expect Kubernetes would still be written in Java.

Re: Go is Google's language, not ours

#267
post #168

Earlier quoted context omitted.

Could you name some I’m pretty curious? For my use case it’s a no brainer because only PostgreSQL have a decent GIS extension, last time I checked Oracle was lagging well behind.

- Distributed transactions across cluster nodes - The IDE experience with PL/SQL, including graphical debugging of stored procedures - Compiling PL/SQL to native code for better performance - Running bare metal without an underlying OS - Oracle RAC - The fine tuning options on their JDBC and .NET drivers - A proper C++ driver API

As an "enterprise" Oracle user, I'd give all those up in a heartbeat if Oracle would just support proper indexing on Json values (well CLOBS with a "is json" constraint in Oracle - bleh). Meaning that I wouldn't have to execute ddl to create a function index on each new field path within the json that I want to support. IOW I want a Postgres path ops GIN index which work beautifully.

Re: Go is Google's language, not ours

#268

Earlier quoted context omitted.

I'd use this as an argument that if PHP is the gold standard for a community-driven programming language, I'd rather every popular language be backed by a large corp haha. Actually, even ignoring PHP, I'm vaguely convinced it's generally better for a language to be backed by a company. I personally feel more secure knowing that there are people whose full-time job is to take care of the language, and I trust communit…

Purists will agree with you. Pragmatists perhaps not so much. I'm sad to see this opinion every time somebody mentions PHP. PHP may have its flaws. But how can anyone deny the instrumental role PHP has played in building the web as we know it today? The open web, open source, open standards, agile were supposed to be the free market answer to all the flaws of the big old corporations. And for a large part they have s…

> Purists will agree with you. Pragmatists perhaps not so much.

Golang is one of the most pragmatic languages there is.

Re: Go is Google's language, not ours

#269

Earlier quoted context omitted.

Generics was introduced in Java in 2004 with J2SE 5.0[0]. [0]: https://en.wikipedia.org/wiki/Java_version_history#J2SE_5.0

The concept of generics/parametric polymorphism has existed decades prior to that in languages like SML and proven to work rather well.

Every time I get to edit pre-java 5 code is a reminder how useful generics actually are.

Re: Go is Google's language, not ours

#270

Earlier quoted context omitted.

The last two paragraphs of the article address exactly that issue - that it's hard to tell whether the direction of Go development is decided solely by the Go core team or by Google as a corporation.

I don’t really get this distinction. “Google as a corporation” isn’t a thing, it’s a collection of people, some of whom happen to be the Go core team. It’s likely that due to being close to Go developers at Google there’s a bias towards implementing features that would help those people, but I very much doubt the subject of genetics in Go comes up at board meetings.

Implementing features Google needs sooner, rather than later, is one thing, but at some point, Google-the-profit-driven-corporation's needs will contradict the broader Golang community's needs, at which point the question is who "wins"?

What will, on a long enough timeline, come up in board meetings, especially as Google fails to meet Wall Street analyst's expectations, and as the ad-tech space evolves, is how much of Google-the-corporation's money to continue plowing into broader community things, like Golang at all.

Hopefully, by the time that happens, the community will be strong enough to persist, and I use Golang professionally, so I have personal investment for that to be true, but the possible eventuality that it'll end up being in the situation Java is currently in, makes me nervous.

Post reply on HN