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

Russ Cox is stepping down as the Go tech lead

groups.google.com

Post reply on HN
Print view View original

211–220 of 396 posts

Re: Russ Cox is stepping down as the Go tech lead

#211

Post by kovac »

SatvikBeri wrote: post #113
darby_nine wrote: post #68

Earlier quoted context omitted.

I don't think this is true. Python had a BDFL and it didn't seem to benefit much from it. I'm not sure what other projects this attitude draws from. Off-hand I'd guess it causes less drama but no appreciable increase of quality, just like other forms of bureaucracy. Meanwhile there's entire landfills of failed projects with single owners who couldn't bend enough. We just don't find this worth discussing. Of course th…

Here are some other projects that benefited from BDFLs in my opinion: * Keras * Ruby * Clojure * Zig * OCaml * Vim * Elixir I think all of these have ended up being unusually coherent. I may not agree with their design philosophy, but there clearly is one.

Linux, OpenBSD? Perhaps to an extent Mutt too.

Re: Russ Cox is stepping down as the Go tech lead

#212

Post by jdnendjjd »

foldr wrote: post #190
nasretdinov wrote: post #183

Earlier quoted context omitted.

Iterators definitely have one of the strangest syntaxes I've seen, but if you promise not to break the language you better not introduce new syntax without a Major reason (like generics, but even those actually introduced next to no new syntax, even re-using interfaces o_O).

Iterators don’t really introduce any new syntax, strange or otherwise.

That's what he said

Re: Russ Cox is stepping down as the Go tech lead

#213

Post by jdnendjjd »

valyala wrote: post #205
vyskocilm wrote: post #14

Earlier quoted context omitted.

Well written list of what made Go better language during last years. I'd add iterators, the recent big thing from Russ.

Iterators and generics go against the original goals of Go - simplicity and productivity. They complicated Go language specification too much without giving back significant benefits. Iterators and generics also encourage writing unnecessarily complicated code, which makes Go less pleasant to work with. I tried explaining this at https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1...

This argument is brought up again and again, but it is just wrong.

Go had both generics and iterators from the get go. Just not user defined ones.

Thus it is obvious that the creators of the language always saw their need for a simple and productive language

Re: Russ Cox is stepping down as the Go tech lead

#214

Post by klabb3 »

serial_dev wrote: post #164
cookiengineer wrote: post #158

Earlier quoted context omitted.

The reluctancy to introduce new syntax too quickly (looking at you, TC39 and Babel) makes go an almost maintenance free language. If you learned idiomatic go, you can maintain and patch other libraries in the ecosystem very quickly. Unified codestyle, unified paradigms, unified toolchain. It's a language with harsh opinions on everything. If you manage to get over your own opinions, you'll realize that any opinion up…

This! In Go, a feature needs to have an extremely good reason to be added, and even then it's only added with care and caution. In other languages, pointless features are added because maintainers are afraid, or not empowered to say... "yeah, we get it, but no, we will not add cruft to the language because you can't write your own 2 line function to achieve the same, no matter how hard you dunk on us on Twitter, it's…

Yes about the language but also Google understands that both tooling and standard library is more important than the language. All of that makes Google internal maintenance much much better. Another artifact of google3 was the absolute shitshow of GOPATH and abysmal dependency management – because Google didn’t really need it, while people outside suffered. When they added go mod support Go became 10x more productive outside of Google.

Go is almost an anti-language in that sense, reluctantly accepting shiny lang features only after they’ve been proven to address major pain points. It’s almost more an “infrastructure deployment toolkit” than a language. Which strangely makes it extremely pleasurable to work with, at least for network-centric applications.

Re: Russ Cox is stepping down as the Go tech lead

#215

Post by lifty »

KronisLV wrote: post #166
cookiengineer wrote: post #158

Earlier quoted context omitted.

The reluctancy to introduce new syntax too quickly (looking at you, TC39 and Babel) makes go an almost maintenance free language. If you learned idiomatic go, you can maintain and patch other libraries in the ecosystem very quickly. Unified codestyle, unified paradigms, unified toolchain. It's a language with harsh opinions on everything. If you manage to get over your own opinions, you'll realize that any opinion up…

With it being so consistent and predictable, I wonder why it hasn’t displaced .NET and Java in the enterprise for back end development. Maybe because a framework like ASP.NET or Spring that covers like 80+% of the enterprise needs hasn’t quite emerged? Or perhaps we just need to give it a decade or so. There are still very few Go jobs in my country, most are either .NET, Java or PHP.

In my enterprise neck of the woods Go is steadily taking over backend development.

Re: Russ Cox is stepping down as the Go tech lead

#216

Post by ahoka »

thayne wrote: post #122
LudwigNagasena wrote: post #87

Earlier quoted context omitted.

> non-nilness Ah, I still remember this thread: https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...

Wow, that's painful to read. Separating the concept of pointers and nullable types is one of the things that I think go having from the beginning would have made it a much better language. Generics and sum types are a couple of others.

False things programmers believe:

All reference types should be able to take a null value.

It's impossible to write complex and performant programs without null.

It's impossible to write complex and performant programs without pointers.

References always hold a memory address in a linear address space. (Not even true in C!)

Every type is comparable.

Every type is printable.

Every type should derive from the same common type.

All primitive types should support all kind of arithmetic the language has operators for.

The only way to extend an existing type is to inherit from it.

What else?

Re: Russ Cox is stepping down as the Go tech lead

#217

Post by foldr »

jdnendjjd wrote: post #212
foldr wrote: post #190

Earlier quoted context omitted.

Iterators don’t really introduce any new syntax, strange or otherwise.

That's what he said

In part of the comment yes, kind of, but the comment begins by saying "Iterators definitely have one of the strangest syntaxes I've seen". As there is no syntax specific to iterators in Go, I find this a bit hard to understand.

Re: Russ Cox is stepping down as the Go tech lead

#218

Post by mseepgood »

galkk wrote: post #61
vyskocilm wrote: post #14

Earlier quoted context omitted.

Well written list of what made Go better language during last years. I'd add iterators, the recent big thing from Russ.

Wow. I haven't followed Go for a while, thanks for that note. Iterators are very nice addition, even with typical Go fashion of quite ugly syntax.

They don't have any syntax that differs from the previous Go versions.

Re: Russ Cox is stepping down as the Go tech lead

#219

Post by tm-guimaraes »

weinzierl wrote: post #189
jeffrallen wrote: post #151

Earlier quoted context omitted.

A goal of Go was to put working on complex distributed systems within the reach of the junior people Google had access to in the quantity they were hiring. To whit, the kind of people who would have been able to work on a big Python system with 3 months ramp up or on a big C++ system with a year of ramp up. It is pretty clear that with respect to that goal, Go is a success. It has attracted Python programmers who nee…

> "Introducing a junior person to a large Rust system would still take a year, because it is so much more difficult than Go." A recent study done at Google disagrees with this assessment. ""it takes about the same sized team about the same time to build it, so that's no loss of productivity" , said Google's Director of Engineering Lars Bergstrom about porting Go to Rust in the talk https://youtu.be/6mZRWFQRvmw?t=2701…

Time to build a new system and time to onboard a new team member without professional experience in a given language are 2 very difficult things.

Go is much more optimised for quick onboarding, fast feedback, more “code look” consistency across projects then rust.

Now a team that knows both rust and go well might have the same proditivity in rust and go (maybe even more in rust), but with lots of changes in personell, specifically in quick growing departments, go can make a huge difference.

This is obviously just an anecdote, but i’ve seen more companies or departments running mostly a go backend stack, having job postings saying “no go experience required”, than the equivalent other companies (or departments ) focused on any other lang.

Re: Russ Cox is stepping down as the Go tech lead

#220

Post by klabb3 »

thayne wrote: post #122
LudwigNagasena wrote: post #87

Earlier quoted context omitted.

> non-nilness Ah, I still remember this thread: https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...

Wow, that's painful to read. Separating the concept of pointers and nullable types is one of the things that I think go having from the beginning would have made it a much better language. Generics and sum types are a couple of others.

> Wow, that's painful to read.

And the dismissive tone of some people including Ian. But to be fair before Rust there was definitely this widespread myth in the dev hivemind that nullable pointers is just the cost of performance and low level control. What’s fascinating is how easy and hindsight-obvious it was to rid code of them. I’ve never had to use pointers in Rust and I’ve worked on quite advanced stuff.

Post reply on HN