Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

Post reply on HN
Print view View original

431–440 of 679 posts

Re: Go is Google's language, not ours

#431

Post by baby »

crimsonalucard wrote: post #52
theshrike79 wrote: post #37

Earlier quoted context omitted.

In my opinion the way they are handling adding Generics to Go is proof of this model working. They are actually trying to pick the implementation that solves real world issues, not just trying to tick [x] Generics in the Go spec sheet.

Parametric polymorphism is a real world issue. The fact that it wasn't checked off indicates to me that they are of the opinion that it's not as important. It's ok to have this opinion, I just disagree with it. I do agree that it's important to think it through, I do not agree that the language should be brought to 1.0 without it.

It would objectively have made Golang harder to read. Can we agree on that? People tend to abuse generics.

Re: Go is Google's language, not ours

#432

Post by DannyBee »

silvester23 wrote: post #82
jmtulloss wrote: post #23

The article uses "Google" instead of individuals names to make the actions taken seem like sinister actions of a faceless corporation. My interpretation is that Google employs a tight-knit group of people that work on Go and collectively are the BDFLs of the language. This isn't that much different from most large OSS projects, although it does seem likely that this core team weights the opinions of those that they i…

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.

Which is nonsense, and is equivalent in this case to "i never bothered to ask so i'm just going to assert some stuff that agrees with my viewpoint".

They could have just asked.

In fact I can answer this for you, since I was the relevant director (IE Go directly reported to me)

It was driven by the core team, and more particularly, the leads and what they want to be trying to do.

I have provided precisely 0% of the vision there.

Further, the org/etc they belong to has changed (a very small number of times) over the past 10+ years depending on the Go team goals, not depending on Google's goals.

(IE when their goals have changed, or the org goals changed, Google has put them in a place that aligns with their goals, not tried to align them to the goals of the org they belong to)

Re: Go is Google's language, not ours

#433

Post by baby »

szuze wrote: post #153
pa7ch wrote: post #17

Many like Go because it is an opinionated language. I'm not sure that a 'community' run language will create something like that because there are too many opinions. Many claim to represent the community, but not the community that doesn't share their opinion. Without clear leaders I fear technical direction and taste will be about politics which seems more uncertain/risky. I like that there is a tight cohesive group…

If you give Go to the community, the community will add exceptions... yuck.

And generics, ew

Re: Go is Google's language, not ours

#434

Post by josefx »

pflats wrote: post #334
jacques_chester wrote: post #241

Earlier quoted context omitted.

A major thesis of the article is that even if something was successful outside of the core team, they would ignore it in favour of their own ideas. Go modules is the reference case.

Go modules is exactly the reference case, but let me expand on that a smidge, because that was when this become crystal-clear to me. There's one exchange in a blog post linked from the article[1] about dep/modules that I think is illustrative of the entire issue (double >> are quotes in the article from Google/go, single > are commentary from the linked blog author): >>Although it was a successful experiment, Dep is…

> Google was saying "from day one" it was a literal showstopper,

For a long time people on the C++ standards committee insisted that we need trigraphs because it had to support systems that didn't even have ASCII. We still don't have pragma once as a standard replacement for include guards because other people seem to compile on some crazy network typologies where it cannot reliably identify files. Taking every "literal showstopper" serious without questioning its merits gets you stuck with C++98 and a lot of quickly accumulating legacy cruft.

Re: Go is Google's language, not ours

#435

Post by 0815test »

pflats wrote: post #334
jacques_chester wrote: post #241

Earlier quoted context omitted.

A major thesis of the article is that even if something was successful outside of the core team, they would ignore it in favour of their own ideas. Go modules is the reference case.

Go modules is exactly the reference case, but let me expand on that a smidge, because that was when this become crystal-clear to me. There's one exchange in a blog post linked from the article[1] about dep/modules that I think is illustrative of the entire issue (double >> are quotes in the article from Google/go, single > are commentary from the linked blog author): >>Although it was a successful experiment, Dep is…

> Dep does not support using multiple major versions of a program in a single build. This alone is a complete showstopper. Go is meant for large-scale work, and in a large-scale program different parts will inevitably need different versions of some isolated dependency.

This has zilch to do with not being community led, so perhaps the complainers should fish for better arguments. Rust makes the exact same call wrt. this particular issue, and it's very much a community-led language, with a public RFC process.

Re: Go is Google's language, not ours

#436

Post by emj »

mieseratte wrote: post #340
bad_user wrote: post #321

Earlier quoted context omitted.

Misconceptions mostly. Java developers are some of the most conservative developers around. And there you have the answer to why Java hasn't evolved that much, or when it did, why it needed to care deeply about backwards compatibility at the source level. It's because Java developers want it that way. The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring e…

> Java developers are some of the most conservative developers around. You're right, there are loads of conservative Java developers. It's one of the the things that makes me love using the language. > The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annot…

Spring is terrible in that sense, and you do find professionals arguing for Spring and strongly typed language. That said it's not an argument I've ever heard before being part of a Spring centric shop.

Re: Go is Google's language, not ours

#438

Post by insertnickname »

Raidion wrote: post #384
bunderbunder wrote: post #335

Earlier quoted context omitted.

> Java has only things that were proved to work in other languages. But they still somehow keep finding ways to make them not work so well when implemented in Java. C# may move faster, but its design team is also much more methodical about ensuring that new features have good ergonomics. In Java, I tend to feel surrounded by hacks that were hastily slapped on in an effort to keep up with C# and, increasingly, Kotlin.

Idk, have you seen the interfaces with default implementations in latest C#? Also duck typing? Both are mistakes IMO. First missteps I feel like I've seen C# make.

What duck typing? Are you talking about the `dynamic` keyword?

Re: Go is Google's language, not ours

#439

Post by oaiey »

movedx wrote: post #299
oaiey wrote: post #193

Earlier quoted context omitted.

I even think that for language and base class library design a strong ownership is key to success. They make the language consistent and the library easy to learn. In both aspects, just compare .NET/C# with PHP.

Exactly. I want my language to be crazy good and have an amazing library to tap into. In fact, it was Go's great standard library (JSON parsing, hardened prod' ready HTTPS server, SSH, crypto, etc) that formed a large part of why I love the language. And yeah, I'd rather go with .NET/C# over PHP any day (although I understand PHP is getting better and better, which is good to hear.)

Well PHP and .NET do not play in the same league. But it is about consistent language and library design. Great failure in PHP and great success in .NET/C#.

I developed PHP till 2007, then as a hobby project in 2013. Massive improvement. And I heard very good things about performance the last years. Swoole even can compete with the top tear languages

Re: Go is Google's language, not ours

#440

Post by ashton314 »

iends wrote: post #316
keithnoizu wrote: post #274

Earlier quoted context omitted.

It's okay, I like elixir's take on things more and I question how suitable Go is for maintainability of large projects. But it's okay. It will improve as more developer tools and language features come online.

It seems to me that you’re going to have a lot more trouble maintaining Elixir code than Go code over the long run.

What makes you say that?

I personally don't see Go and Elixir's primary domains as being equal, or one a superset of the other. So there's some argument to be made about the region where they overlap, but for something inherently based around fault-tolerance and distribution, seems to me that code written to run on the BEAM will be smaller and clearer and therefore more maintainable.

Post reply on HN