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

671–679 of 679 posts

Re: Go is Google's language, not ours

#671

Post by BrandoElFollito »

josefx wrote: post #364
szuze wrote: post #153

Earlier quoted context omitted.

If you give Go to the community, the community will add exceptions... yuck.

Go already has panic/recover which where explicitly proposed as an exception like mechanism for go.

The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values. -- https://blog.golang.org/defer-panic-and-recover

I belive this means that using this mechanism similarly to try/except in Python is not possible (I write 20 lines in go so this is quite a wild guess)

Re: Go is Google's language, not ours

#672

Post by divan »

pote wrote: post #655
divan wrote: post #628

Earlier quoted context omitted.

The fact is Go team learns from other implementations and it's clear from talks and articles. Another fact is that you're accusing them in having the "mindset of refusing to look at established work". Those two facts don't get along together, that's why I disagree.

They stuck their heads in the sand refusing to have a package manager for like 8 years and asking people to put dependencies on a vendor folder. That's not learning from established work.

First, Go had package management – it just has been optimized for monorepos.

Second, since early days of Go, they said that acknowledge their Google monorepo bias, and can't implement package manager that works for everybody without understanding what people outside of Google need. They consciously gave time for community to grow and mature and get enough feedback before implementing proper solution, while actively studying package management solutions from other languages.

I definitely can't call it "refusing to learn from established work". Of course, they could've just copy existing suboptimal solutions without properly giving it a thought – that's what most of the languages do, after all – but that's where Go choses another path.

Re: Go is Google's language, not ours

#673

Post by grumpydba »

masklinn wrote: post #653
grumpydba wrote: post #458

Earlier quoted context omitted.

> You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements. It looks like you are in golang core team's minds. You appear to be able to judge intent. Impressive quality you have here.

> It looks like you are in golang core team's minds. You appear to be able to judge intent. Not at all, Rob Pike stated it fairly explicitly if in somewhat milder terms: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilli…

> users of Go are peons who can't be trusted with sharp implements.

Pike himself is a user.

Re: Go is Google's language, not ours

#674

Post by gerbilly »

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…

It's funny I feel the opposite.

I feel Go's 'opinionated' language design insults my intelligence.

Re: Go is Google's language, not ours

#675

Post by meddlepal »

xyzzy_plugh wrote: post #461
meddlepal wrote: post #446

Earlier quoted context omitted.

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

> we need better tools Sure, and the "right tool for the right job" is still my mantra. Go is a very good at solving for an incredible amount of tasks in many problem spaces. Users will always want to bend tools to work in new places, and that's okay -- sometimes it isn't a fit. Have some business requirements that make using Go a chore or a pain? Use a different language, or restructure the requirements.

> Have some business requirements that make using Go a chore or a pain? Use a different language, or restructure the requirements.

That's such a cop out answer when our industry is basically doing fad-oriented engineering. It's great when you can greenfield build a project but when you're taking over a project the selection of language has usually been decided. Or you know the management team has decided for hirability reasons to use X. Or just legacy requirements don't match reality eventually.

This is why we need more expressive languages than Go. Requirements change over the course of a projects life and what made sense in year 1 rarely makes sense several years later.

Re: Go is Google's language, not ours

#676

Post by collinmanderson »

spopejoy wrote: post #667
baby wrote: post #620

Earlier quoted context omitted.

These are not bad things if you’re writing system code.

Is there ever a plan for GC?

I feel like not having a GC is rust’s biggest advantage over higher level languages. It allows rust to work in environments that only languages like C, C++ can work in. (Embedded, shared libraries, etc)

Re: Go is Google's language, not ours

#677

Post by user5994461 »

mcguire wrote: post #579
DannyBee wrote: post #432

Earlier quoted context omitted.

Which is nonsense, and is equivalent in this case to "i never bothered to ask so i'm just going to assert some stuff that agrees with my viewpoint". They could have just asked. In fact I can answer this for you, since I was the relevant director (IE Go directly reported to me) It was driven by the core team, and more particularly, the leads and what they want to be trying to do. I have provided precisely 0% of the vi…

So, why is Google paying them? Is Google getting enough value out, or PR, or...?

Google is getting tremendous value from Go, on multiple fronts.

For reference, Go was meant as an alternative to Java and C++, to develop distributed systems. Given the direction that Java went, acquisition by Oracle and $10B lawsuit against Google, it is a well worth having an alternative.

Re: Go is Google's language, not ours

#679

Post by spopejoy »

collinmanderson wrote: post #676
spopejoy wrote: post #667

Earlier quoted context omitted.

Is there ever a plan for GC?

I feel like not having a GC is rust’s biggest advantage over higher level languages. It allows rust to work in environments that only languages like C, C++ can work in. (Embedded, shared libraries, etc)

I more meant "GC for those who want it", as advanced GC with Edens and mark-sweep tenured generations can handle high-allocation and large-heap scenarios that are extremely challenging for simpler MM approaches. I don't know if this really can be done as a library though.
Post reply on HN