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

511–520 of 679 posts

Re: Go is Google's language, not ours

#511

Post by jeanlucbernard »

doesnt_know wrote: post #162

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…

What are the advantages of having a committee involved in the design of Go? In the case of C++, based on the threads that I read on HN, I see people being unhappy about the decisions taken by its committee.

Re: Go is Google's language, not ours

#512

Post by weberc2 »

dnautics wrote: post #484
baby wrote: post #418

Security consultant here. I have audited many codebases in many languages. Go is by far the easiest language to audit: it always looks the same, it's not too verbose, there are no generics or OOP. Coincidentally it's always the most secure as well. My take on this is that it is easier to see logic problems because it is easier to read, understand and reason about. On top of that the standard library does so much for…

> it's not too verbose that's a really puzzling statement to me, maybe aside from C, C++, and Java, (and maybe rust) Go is certainly on the "more verbose" side.

Pretty sure those are almost all of the most popular statically typed languages (absent C#, which has about the same verbosity as Java). I'm sure I'm wrong if you're willing to lower the threshold for "popular" enough.

Re: Go is Google's language, not ours

#513

Post by logicprog »

pkaye wrote: post #476
logicprog wrote: post #449

Earlier quoted context omitted.

I'm curious, how will they end Go itself? My understanding is that they always planned to have generics, they just didn't make 1.0 and now the Go community has sort of adopted the lack of them like a badge of honor. Also, I have no expertise in your field so forgive me if this is a stupid question but wouldn't generics be easier to check over since they allow there to be only one implementation of something for all t…

I think there is generics proposal under discussion.

There is! As soon as it is implemented in the language, I will consider Go.

Re: Go is Google's language, not ours

#514

Post by erik_seaberg »

baby wrote: post #431
crimsonalucard wrote: post #52

Earlier quoted context omitted.

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.

Uses of https://golang.org/pkg/sync/#Map are objectively harder to read than if they allowed a library to implement a type that conforms to builtin map[K]V. Instead you have to learn method names and cast return values, and builtin maps don't even support those methods.

Re: Go is Google's language, not ours

#515

Post by teddyh »

ncmncm wrote: 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.

I agree completely, but good luck convincing people around here; I’ve had no luck for a few years now¹²³. It may be an age/experience thing – you might need to have been burned by it a few times before you learn not to build your house upon the sand.

1. https://news.ycombinator.com/item?id=8733705

2. https://news.ycombinator.com/item?id=17162582

3. https://news.ycombinator.com/item?id=18370067

Re: Go is Google's language, not ours

#516

Post by apta »

Retra wrote: post #483
apta wrote: post #460

Earlier quoted context omitted.

Or, you can view this from another angle, that the golang authors yet again disregarded previous established work in the industry for the sake of avoiding hard work in the language and the compiler. It's no wonder the time package in golang is garbage compared to established offerings in mature languages like Java and C#.

It's no wonder that a new language is lacking the maturity and features of an old language. Of course you can attribute it to 'avoiding the hard work', but that's the same reason you don't live in a crystal castle. A more salient criticism would highlight what they have been spending their time on, rather than pointing out that they haven't spent much time on something.

The logical thing to do is to build on what other languages did, and use established practices. Comparing what Rust did to golang when it comes to generics for example is enough to show the mentality of the golang authors refusing to look at established work.

Re: Go is Google's language, not ours

#517

Post by stcredzero »

crispinb wrote: post #250
doesnt_know wrote: post #162

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…

> The last thing I personally want to see is Go being handed over to the community to be designed by committee. There is a point about diversity to be made here. Different design models will each have their strengths and weaknesses, and the design spaces each opens up are not going to be fully explored if one model prevails. So I'm glad there's a language like golang with a coherent centrally-planned vision behind it…

There is a point about diversity to be made here.

Strings in C++?

Re: Go is Google's language, not ours

#518

Post by stcredzero »

jerf wrote: post #374
weavie wrote: post #208

Earlier quoted context omitted.

I think a big part of the success of Haskell is down to its language extensions. New features are introduced as off by default and can be opted into. This allows all kinds of crazy features to be introduced without really impacting users if they don't want to. It does allow the community to be quite experimental without fear of destroying things.

Haskell also has the motto "Avoid 'success at all costs'."[1] What that means is not that they want to fail at the things they set out to do, but that they want to ensure the language is never in a position where it's so important that certain behaviors or code be kept exactly the same because there's too much code that depends on it in the wild that they can't experiment with some new interesting feature in the next…

they want to ensure the language is never in a position where it's so important that certain behaviors or code be kept exactly the same because there's too much code that depends on it in the wild that they can't experiment with some new interesting feature in the next release.

Squeak Smalltalk had this. "Burn the diskpacks!"

Re: Go is Google's language, not ours

#519

Post by saghm »

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…

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

Top 20?

Re: Go is Google's language, not ours

#520

Post by pjmlp »

pron wrote: post #503
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.

C# has made some serious mistakes: reified generics (which has basically destroyed simple language interop on the CLR and makes it an unattractive target for language implementors), and recently, async/await. Both of these help in some ways, but have costs that are higher than the benefit and much better alternatives. Java is not trying to "keep up." It is intentionally slow-moving and conservative (this design goal…

As former Java dev, returned into .NET world, I don't consider it a mistake, the CLR was designed with multiple languages in mind, and there are plenty of options available, even if Scala devs failed at that.

On the other hand, what I consider a major mistake from Java side was ignoring value types and AOT compilation since it's inception.

Had Sun blessed such features since the beginning, and many use cases for C and C++ wouldn't be necessary.

Post reply on HN