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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

81–90 of 402 posts

Re: The State of Go

#81

Post by dilap »

grabcocque wrote: post #6

The best summary I read recently is that go isn't a bad language, nor is it a particularly good one. What fascinates me is the way the Golang community have concretised that essential middle-of-the-roadness as the language's prime virtue. That, of course, has long been Java's prime virtue as well. (see Blub Paradox) By putting "we're okay with being okay" as your Big Thing you're clearly pitching for that vast bulk o…

Nah. I like Go because the language itself is minimal yet powerful, and because the quality of engineering is extremely high. I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools; Go minimizes that.

An excellent example is the handling of this bug report(§):

https://github.com/golang/go/issues/12914

which resulted in this language-change proposal:

https://github.com/golang/proposal/blob/master/design/12914-...

And then these commits:

https://go-review.googlesource.com/#/c/36255/

I feel like any other language I've used would've just added a "monotonicTime" function and called it a day; the Go solution is impressive, elegant, and shows an exceedingly high level of care for the end-outcome results for the users of the language.

To me, that's what makes Go special.

(§After a rocky start; it took the core devs a bit to realize it was a real issue because within Google's special environment it isn't.)

Re: The State of Go

#82

Post by IshKebab »

rpercy wrote: post #35
donpark wrote: post #24

Earlier quoted context omitted.

Go's blandness is a feature to me. It's not a joy to write but pleasant to read and understand which, sadly, won't matter unless Golang gains more popularity.

100% agree re: readability (as I've mentioned elsewhere). I've actually been very surprised at the near-ubiquity of Go in the modern infrastructure/tools space though. Seems like each new OSS product I evaluate is written in Go. See companies like Cloudflare, Hashicorp, InfluxData, CoreOS, and, obviously, big projects like Kubernetes.

I think that's mostly because Go trivially generates static binaries, and cross-compiling is also trivial (as long as you don't use CGo).

I can't actually think of a single other language that matches that. Rust might get there one day but cross-compiling still requires a C cross-compiler (ugh) and C dependencies (e.g. OpenSSL) are often dynamically linked.

Re: The State of Go

#83

Post by skybrian »

MichaelGG wrote: post #65
rpercy wrote: post #10

Earlier quoted context omitted.

Do you have an example of the community celebrating mediocrity? My impression is of a community willing to go without some features, in order to preserve those it values. Namely simplicity, explicitness, terseness, and consistency.

Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…

The preference for maps and folds looks like a fad to me. I can use them but I don't think it makes the code any easier to understand, just different.

Re: The State of Go

#84

Post by spion »

MichaelGG wrote: post #65
rpercy wrote: post #10

Earlier quoted context omitted.

Do you have an example of the community celebrating mediocrity? My impression is of a community willing to go without some features, in order to preserve those it values. Namely simplicity, explicitness, terseness, and consistency.

Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…

Thats not a strength of Go. Structural interfaces, channels and performant M:N green threads are its main strengths, and AFAIK there is no other language that provides a similar combination in a familiar C/ALGOL-like packaging.

If such a language existed and had generics and Swift or Rust style error handling as well as some backing by a large-ish corporation / organization, I think that language would be preferred to Go.

More expresiveness isn't always better. Examples that hit the sweet spot are C# / Swift (C# really needs algebraic data types). Beyond a certain point, you will start to lose users. Haskell is very expressive, but few will ever have the time or patience to learn enough to build their perfect monad transformer stack and take advantage of the mtl typeclasses to easily use it. Even though it does have M:N green threads, channels, STM and everything.

In fact, Haskell could probably compensate for this and beat Go by having excellent library documentation and well written, focused tutorials for the working engineer.

Re: The State of Go

#85

Post by mseepgood »

MichaelGG wrote: post #67
user5994461 wrote: post #58

Earlier quoted context omitted.

Go is meant for distributed systems. All these companies, and generally speaking a lot of infrastructure thing is in that domain. They use the right tool for the job.

Can you elaborate on why Go the language is "meant for" distributed systems?

It has been explained on multiple occasions by the language designers what they meant it for, e.g. https://talks.golang.org/2012/splash.article

Re: The State of Go

#86

Post by aeturnum »

artursapek wrote: post #20
grabcocque wrote: post #6

The best summary I read recently is that go isn't a bad language, nor is it a particularly good one. What fascinates me is the way the Golang community have concretised that essential middle-of-the-roadness as the language's prime virtue. That, of course, has long been Java's prime virtue as well. (see Blub Paradox) By putting "we're okay with being okay" as your Big Thing you're clearly pitching for that vast bulk o…

What on earth is a "good" language? > you're clearly pitching for that vast bulk of mid-quality developers that make up the huge middle chunk of corporate devs That was actually something Google aimed for with Go, and I don't see what is shameful about it. It's a simple language on purpose. It is meant to be easily learned by any developer, and similarly Go code is meant to be easily read. Also, what sets Go apart fo…

When I think about Go in comparison to other languages, I think of car metaphors. Lots of people talk about cars that are good. Some people think a good car is fast, some people think a good car is low maintenance, some people think a good car is eye-catching. They are all right, those are all descriptors of good cars.

Go, however, is like a Toyota Corolla or a Honda Civic. It's dependable, but relatively plain. It's not necessarily a joy to drive but there's not much of a learning curve. It lets you go fast, but not so fast you'd hurt yourself. It's designed with safety in mind, so much so that it can feel a little over-bearing at times.

It's not a language that draws you in with one clear feature or philosophy. I've used it very successfully and I still find myself rolling my eyes at "go-isms." Lines of "ok, err = ...", rewriting extremely similar data structures, careful channel management, etc. In a list of dependencies, the go dependency will need the least maintenance time and tuning, but what you do need will often be drudgery.

Go is a useful language, but it's a language that has purposefully stripped out all the magic. People like magic, they miss it.

Re: The State of Go

#87

Post by mseepgood »

dtech wrote: post #25
mseepgood wrote: post #13

Earlier quoted context omitted.

> And no type safety! 90% type safety (probably even more) is more than no type safety. It's not a holy grail that all programming must strive for.

It's a balance, but I am fairly disappointing that such an up-and-coming language has such a limited type system. In the days where even traditionally fully untyped languages are moving toward inferred, optional and static typing [1],[2],[3] I'm disappointed to see `interface {}` sprinkled throughout Go API's. [1] JS Typescript and flow: https://www.typescriptlang.org/ , https://flowtype.org/ [2] Python with mypy: ht…

> In the days where even traditionally fully untyped languages are moving toward inferred, optional and static typing

This only shows that the sweet spot is probably not in the extremes, but somewhere in between the dynamic type system - paranoid type system spectrum.

Re: The State of Go

#88

Post by Groxx »

dilap wrote: post #81
grabcocque wrote: post #6

The best summary I read recently is that go isn't a bad language, nor is it a particularly good one. What fascinates me is the way the Golang community have concretised that essential middle-of-the-roadness as the language's prime virtue. That, of course, has long been Java's prime virtue as well. (see Blub Paradox) By putting "we're okay with being okay" as your Big Thing you're clearly pitching for that vast bulk o…

Nah. I like Go because the language itself is minimal yet powerful, and because the quality of engineering is extremely high. I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools; Go minimizes that. An excellent example is the handling of this bug report(§): https://github.com/golang/go/issues/12914 which resulted in this language-change proposal: https://github.com/…

I dunno... in some ways, the problem is that they didn't think it through to begin with, and chose something widely-known-to-be-ambiguous-and-problematic like "time.Now()", instead of choosing unambiguous names / structures from the start.

It's kinda the equivalent of making a new language (nowadays) and not defining what encoding your native strings use. Of course it's going to cause problems. Except the timer issue has been around much longer than the standardization on utf-8.

Re: The State of Go

#89

Post by maehwasu »

chimeracoder wrote: post #74
joaodlf wrote: post #14

I don't share some of the opinions I see in the comments here. I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point. But the n#1 thing for me in Go is: It's written…

> Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me. I've been writing Go full-time as my primary language for nearly five years. Before that, my languages of choice were Lisp[0] and Python, with R as a very distant third choice[1]. I have always been a polyglot and enjoyed experimenting with any new language I could try out - you'd be hard pressed to name a non-esoteric la…

> Seriously, I have never found a language that made refactoring as easy - or, dare I say fun? - as Go.

Sounds like someone's ready for Haskell.

Re: The State of Go

#90

Post by zirtec »

Definitely the talk I enjoyed the most at FOSDEM today. Both instructive, relevant and pleasant to listen to. Glad to see things like sort.Slice or JSON rendering. When you're spoiled with python or groovy, you miss them them badly.
Post reply on HN