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

441–450 of 679 posts

Re: Go is Google's language, not ours

#441

Post by weberc2 »

pjmlp wrote: post #422
weberc2 wrote: post #417

Earlier quoted context omitted.

Go is a language for software engineering, which entails pragmatic human factors. It's not a computer science language, which emphasizes theory.

Eiffel and Ada are languages for proper software engineering. Go not so much, specially given its toy type system, where one cannot even do Type Driven Design.

> proper software engineering

Only if you define this in such a way that it's tautologically true. If your definition of software engineering incorporates some degree of economic success, then no, these languages don't work well.

I'm sure someone will be tempted to levee this strawman argument: "But lots of languages drive projects that make more money than Go!" Note that I never claimed market success was the sole criteria.

Re: Go is Google's language, not ours

#442

Post by miguelmota »

Agree that generics are much needed but also wary that if you let the community take charge then you end up with a frankenstein language like PHP.

Also a huge fan of go mod over vgo so I had no issues of them scrapping the community dependency manager and rewriting it to be part of the language

Re: Go is Google's language, not ours

#443

Post by insertnickname »

TheCondor wrote: post #353
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.

That this very thread exists suggests a certain “C++ ification” that happens to languages. I really respect the slowness of the go maintainers in adding new stuff. I also suggest that we all ponder our tooling some; Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you.

>Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you.

It's not so much the extra typing that's the problem, it's the extra reading. All the stuttering is visual noise.

Re: Go is Google's language, not ours

#445

Post by skybrian »

There is an assumption here that the community is unified, you are part of the community, and therefore if the community doesn't get what it wants, then you don't get what you want.

Actually, the community disagrees on stuff, so you're unlikely to get what you want, regardless. The only way you always get what you want is if you write your own language. (Assuming you're skilled enough to implement it.) But a language nobody else uses is of little benefit.

There needs to be some core team that makes coherent decisions. Unless the community is tiny, the core team is not the community. There are inherently tensions. However it's unclear that Go's core team is doing worse at listening to their community than other language's core teams?

Re: Go is Google's language, not ours

#446

Post by meddlepal »

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.

> For me it was like going back to being 8 years old on my Commodore Plus/4 and really enjoying writing code again.

Your comment is the problem with the Go community. I have seen a number of comments from Golangers that they want a "fun" language that helps them reminisce about the past. They also want to write a lot of senseless boilerplate because for them more typing is somehow about them reliving their past. And tracking down nil pointers... and writing containers for every concrete type.

The simple fact is software development has gotten more complex because business requirements have changed and Go does a poor job of addressing that with its limited feature set. The rest of the programming world has accepted that we need better tools whether it be toolchain stuff or language features. Hate on Java all you want but at least it, like most other non-Go languages, has realized the need for better tools in the toolbox.

Re: Go is Google's language, not ours

#447

Post by steveklabnik »

0815test wrote: post #435
pflats wrote: post #334

Earlier quoted context omitted.

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

Rust does support multiple major versions of dependencies in a build.

The only thing we don’t allow is multiple copies of dependencies that link to native libraries, and the -sys pattern means that this is rarely an issue in practice.

Re: Go is Google's language, not ours

#448

Post by computerex »

divan wrote: 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…

The article barely even talks about generics, though (and takes a favorable position towards the Go team). What are you on about? Did you read the same article I did? https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGoo...

The author's primary complaint is the way Go modules were handled, namely that one member of the Go core team overrode the entire community.

Re: Go is Google's language, not ours

#449

Post by logicprog »

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…

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 types versus in Go, a bunch of different implementations of the same thing that you have to check and might have subtle errors?

Re: Go is Google's language, not ours

#450

Post by akarki15 »

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

> New Cool Thing See that's your issue. Go tries super hard to _not_ be that and evidently has succeeded.
Post reply on HN