Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

271–280 of 679 posts

Re: Go is Google's language, not ours

#271
post #74
post #6

This. But Go is one in a long line of proprietary languages that those of us who have been around the block know to stay away from. Recently: Java was Sun's, C# is Microsoft's, Swift is Apple's, Go is Google's. With any luck, all will be footnotes in ten years. Those of us who knew better than to get invested in them will be fine. Everyone else gets a chance to learn something.

> 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

> Go, still uncertain

A lot of the tools in the modern ops ecosystem are written in Go, and that trend is not slowing down. Not even going to start to list them. A lot of devs also love Go and it has a very nice community. If you would have said this 5 years ago? Sure - but now it's past the 10y mark in age - I think it's safe to say Go isn't going to go away any time soon.

Re: Go is Google's language, not ours

#273
post #261
post #245

Earlier quoted context omitted.

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…

True. Those are all good points. I do still feel the upsides more than make up for it, but yes I am glad I'm not responsible for developing any external tools for Haskell!

Re: Go is Google's language, not ours

#274

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…

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.

Re: Go is Google's language, not ours

#275
post #222
post #182

Earlier quoted context omitted.

Visual Basic and VB.NET are two very different beasts, only sharing a name. The VB6 runtime is indeed updated to run, but really how much update does it need beyond sticking the DLLs around? The VB4 and VB5 runtimes run perfectly fine on Win10 and those had no updates for it. It all relies on Win10's overall backwards compatibility.

They are still pretty similar, Microsoft re-introduced quite a few features back.

They are similar only on a superficial level, at their core they have not only vast differences in terms of how they work but they also have a different philosophy. It is not a matter of what you can do in terms of features, but also how you do it and how that affects the IDE, which is a core element of VB6 as opposed to VB.NET where you could be using whatever text editor or IDE you want (it isn't a coincidence that VB6 has its own IDE whereas VB.NET is using the same IDE as C# and C++).

VB6 isn't just the language, if anything the language is a minor part of it. VB6 is the entire tool, including the language, IDE and library. You cannot separate these, they are written for each other. This is also what pretty much all VB6 alternatives get wrong as they try to reuse elements designed for something else. You cannot do that and get something like VB6 beyond at a superficial level (and this is exactly what Microsoft did with VB.NET).

Re: Go is Google's language, not ours

#277
I really wish Go had learned a lesson from Java: programmers will eventually want generics, and adding generics to a language that was not designed for them leads to new and unexpected obstacles.

The lack of generics makes Go uniquely unsuitable for functional programming, an unfortunate outcome when functional programming is the New Cool Thing.

Re: Go is Google's language, not ours

#278
post #32
post #14

"... can't we have something like OpenGo ..." > " ... this won't happen ... " I'm confused as to what's stopping someone from forking it, calling it OpenGo, and building a community around that.

This could be done, of course. But how likely is such an approach to succeed? It would effectively create a new language and in turn to a new ecosystem. Why not just use a different language (Rust comes to mind) then?

> It would effectively create a new language and in turn to a new ecosystem.

And that new language would be Go++ (i.e. Go with generics) and what would be wrong with that?

Consider how C++ started.

It was nothing more than a preprocessor extension to the C language called C with classes.

There is nothing stopping that Go++ turning into the Go equivalent of C++.

So back to the previous OPs question, what's stopping someone from forking it?

Re: Go is Google's language, not ours

#279
post #151

It's a dangerous type of articles that deliberately turns community against Go team, based on misunderstanding or plain false accusations. Go team said many times that generics are technical issue, not a political one. (see [1] by rsc (Russ Cox from Go team)) There are also stories like experience report of Cloudflare outage due to the lack of monotonic clock support in Go that led to introducing one. [2] The way how…

In my opinion the monotonic clock example cuts against this argument - originally the core team was extremely dismissive of the idea, even though it had been shown to cause pain for a lot of people: https://github.com/golang/go/issues/12914#issuecomment-15075...

But the implementation that rsc came up with was much better than everything proposed by the community (no API change).

Re: Go is Google's language, not ours

#280
post #213

Earlier quoted context omitted.

It's not about being careful (they are--but always with the baggage of backwards compatibility), it's about not having a soul. Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.) These different paradigms together make for code that does not read the same no matter who writ…

> Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.) So, by adding a feature which works extremely well with OO and enhances the language they have no soul? That doesn't make any sense. Javas soul is being a blue collar language. It leaves the experiments to other (JVM) la…

"Java, from Bell Labs"
Post reply on HN