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

331–340 of 679 posts

Re: Go is Google's language, not ours

#331

Post by iends »

mdale wrote: post #25

It can be forked it if the opinions are widely shared and you think people will support you to run it better ? The tone of the article seemed to be casting shade relative to the institution funding it's development as the foundation of why there are problems ? It's normal in a large scale open lanuage there will be disagreement around direction of the project. Many models around how those disagreements are resolved e…

I’m convinced that the people who just suggest forking an open source project with 100s or 1000s of man years behind it lack practical experience in building or maintaining large software systems.

Dismissing valid criticism with “just fork it if you don’t agree” has got to be some of the most useless advice parroted around open source.

Re: Go is Google's language, not ours

#332

Post by jolfdb »

xaduha wrote: post #268
bartimus wrote: post #161

Earlier quoted context omitted.

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.

Go is pragmatic about language design, but purist about managing community whiners.

Re: Go is Google's language, not ours

#333

Post by RHSeeger »

akerro wrote: post #286
th3iedkid wrote: post #189

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

Generics were added so late because they had to figure out how to do it properly, correctly, on the first time.

And they failed. They did the best they could, but the fact that they were added onto the language later (plus the desire for backwards compatibility) means there are lots of gaps and warts in what they wound up implementing.

Re: Go is Google's language, not ours

#334

Post by pflats »

jacques_chester wrote: post #241
weego wrote: post #133

Earlier quoted context omitted.

Sure, but that's a different issue. If it doesn't gain traction then the decisions made by Google are clearly considered the best approach, at which point what relevance does the openess have?

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 not the right approach for the next decade of Go development. It has many very serious problems. A few:

>>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.

>Russ [a member of the Go team] has asserted this from day one, and has brought several examples out in evidence, but has simply not convinced the committee that it’s true. Calling it a serious problem, let alone a showstopper, is a significant overstatement. The strongest claim that can be made on this point is that it’s a matter of opinion.

That, to me, is that. Go is Google's language, and Google said that for them, not supporting multiple versions of a dependency was a showstopper. The community read that and saw it as a point for debate, and the author continues to try to debate it in the article.

And that's the issue! It was not a point for debate. Google was being forthright. Google was saying "from day one" it was a literal showstopper, and the community seems to have read it as a figurative showstopper. Who was right in this instance is irrelevant; if the community wants to litigate Google's decisions rather than integrate them into their tools/patches/etc., then the community will not get those things adopted into go.

[1] https://peter.bourgon.org/blog/2018/07/27/a-response-about-d...

Re: Go is Google's language, not ours

#335

Post by bunderbunder »

akerro wrote: post #186
danielmg wrote: post #177

For what it's worth I'm a semi-grey beard (20 years in) and I love golang. For me it was like going back to being 8 years old on my Commodore Plus/4 and really enjoying writing code again. It needs close parenting. Java has been ruined by the push to include everyone's pet feature.

>everyone's pet feature Isn't that C#? Java is very slow at adding new features, Java has only things that were proved to work in other languages.

> 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.

Re: Go is Google's language, not ours

#336

Post by mieseratte »

read_if_gay_ wrote: post #311
mieseratte wrote: post #301

Earlier quoted context omitted.

> It needs close parenting. Java has been ruined by the push to include everyone's pet feature. Oracle is moving to a faster cycle of development. There are some of us who strongly feel that some of their decisions are based less on what's best for the language and more on catering to the popular-and-loud crowd. I'll never forgive the addition of `var` to the language.

>I'll never forgive the addition of `var` to the language. I'm inexperienced with Java and didn't know this existed until I saw your post. It seems like a nice shorthand to me. Can you explain why you don't like it?

I'm of the mind that it is un-Java like. Whether or not there is a "Java" as a philosophy is not the hill I'm trying to die on.

Consider these contrived lines of code:

```

String first = someMethodCall();

var second = someMethodCall();

```

The first provides more useful information at a glance. I don't see any value in the "nice shorthand." Typing out "SomeStupidClassName" has never once been a material bottleneck in my 15+ years of programming, but now we have this new option that caters to the lazy, and in doing so makes life harder. Now I have to either ban it, embrace it, or come up with some ruleset around when you can and can't use it. Why? Someone can't be bothered to type a few extra characters.

It reminds of my grandfather, a former professional ball player, but one who played back in the days where there weren't these multi-million dollar celebrity ballplayers pissing and moaning in the press about just how hard their life is. He used to call those types "high-priced cry-babies," and I really feel a tinge of that in dealing with folks who just wholly embrace `var` and give folks like me shit for having criticisms of it. Perhaps that's just my old blue-collar showing but your convenience in writing a handful of characters simple will never enter into my considerations.

I love using Java, I love the addition of things like streams, the Optional type, etc. My sibling comment is a little right, and very wrong. Lots of Java developers have a certain conservatism about them, I'm mostly certainly one. But there are large reasons to hate it.

Re: Go is Google's language, not ours

#337

Post by munmaek »

Illniyar wrote: post #109
munmaek wrote: post #74

Earlier quoted context omitted.

> With any luck, all will be footnotes in ten years. Java and C# are not going anywhere, especially now that .NET works on OSX and Linux. Swift, unlikely. Go, still uncertain. It's fairly short-sighted to criticize a language and hope it dies out in usage just because a corporation is chiefly responsible for it. [0]: https://dotnetfoundation.org/about

Swift has garnered little traction outside iOS development, while other languages are gaining traction inside iOS development (javascript mostly, but Kotlin is also trying to make headway into iOS development). I won't put survival rating for it to be very big. I'm sure Apple would keep it for decades to come, but I'm wouldn't bet on it being anywhere near as popular as it is now in the future.

As long those languages aren't native, they won't be nearly as popular as swift. Swift doesn't need to be adopted outside of iOS development at all, because when people develop iOS apps the main choice will be Swift.

Swift is actually a very pleasant language, and apple provides some pretty good documentation although it could be better.

It's going to play out like this: Swift or Objective-C (for legacy codebases/people who already experts in objective-c and don't want to switch), and some other, slower languages that will always be second class.

Re: Go is Google's language, not ours

#338

Post by ksec »

fnord123 wrote: post #201
ksec wrote: post #118

Earlier quoted context omitted.

If we look at the Top 10 programming languages, I think only Ruby is community driven that has very little cooperate backing. All the other languages are driven by one (Apple;Swift), or multiple, (Javascript, Java) cooperate sponsors. I think the balance is hard, you will need lots of resources from Documentation, VM expertise, Library, etc.

The top 10 according to Red Monk[1] are JavaScript, Java, Python, PHP, C#, C++, CSS, Ruby, C, Objective-C, Swift, TypeScript, Scala, Shell, Go, R, PowerShell, Perl, Haskell, Kotlin. Of these, Javascript (w3), Python (Python Foundation), CSS (w3), C++ (ISO), Ruby (community), C (ISO), Shell (Posix), R (community), Perl (community), and Haskell (community) are not bound to a single company. [1] https://redmonk.com/sogr…

I should have included in my first post. I think rather than splitting between Community or Cooperate, a more accurate representation would be how much Market Value are depending on those Languages. If you have a company dependent on OCaml, let say it is on 30th on the list, but the company is making billions in Net profits, you could bet the company will fund the development of Ocaml, even if it was driven by a Foundation, or Community.

Re: Go is Google's language, not ours

#339

Post by lallysingh »

playing_colours wrote: post #259
cfcf14 wrote: post #214

Earlier quoted context omitted.

I completely agree. When I first started writing Go (coming from Python/C#) I complained an awful lot about what felt like pointless hamstringing of functionality. Go is a simple language, and you don't get many toys. It also feels very verbose at times, and forces you to think a lot about doing things which seem automatic in other languages. However, as time went on, I noticed a few trends. Firstly, forcing me to th…

Interesting, that I saw a similar pattern like "at first I complained, but as time went on I found some benefits" quite a lot. It can be that your learn a language better, became more comfortable with the way it must be used: say, stopped writing code in Elixir the way your used to write in Python. But the other thing is that it's in our human nature that we tend to look for something positive in bad situations we ex…

The nice thing about walking minefields is learning how to watch your step.

Re: Go is Google's language, not ours

#340

Post by mieseratte »

bad_user wrote: post #321
read_if_gay_ wrote: post #311

Earlier quoted context omitted.

>I'll never forgive the addition of `var` to the language. I'm inexperienced with Java and didn't know this existed until I saw your post. It seems like a nice shorthand to me. Can you explain why you don't like it?

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 annotations all static type safety goes out the window.

> Misconceptions mostly.

But drop the strawman argument and borderline ad hominem. It'll do you better.

Post reply on HN