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

201–210 of 396 posts

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

#201

Post by akira2501 »

lenkite wrote: post #172
akira2501 wrote: post #139

Earlier quoted context omitted.

> needs a lot more features to be usable I guess what I'm caught up on is the idea of "usable" is entirely subjective. To my eyes and fingers, Go has been fine without generics, and since their addition I've only used them once to clean up an odd bit of code around instantiating "module" like initializers. > and makes developing in it a miserable experience. Subjective or not I find this a bit harsh. I spent years in…

Please search/replace all `map[x][y]` in your Go projects with `map[sting]interface{}` in order to be honest and consistent with your opinion. And explain to all your stakeholders that you have done so because generics is bad. You have been using a generic data-structure since Go 1.0 but did not realize this.

> in order to be honest and consistent with your opinion

Did you mean replace `map[string]string` with `map[string]interface{}`? You should take a look at Go's runtime map code. This is not a "generic" data structure. It's an unsafe data structure with some thin compiler sugar on top of it which is also something worth taking a look at.

For example see how it handles something like `m["x"]` versus `m[12]` or a map using structs as keys. Put it in Godbolt then chase down the various runtime implementations you encounter. Unless I'm misunderstanding you, then I apologize, but what else did you mean?

> explain to all your stakeholders that you have done so because generics is bad.

I also write code based upon engineering principles and not on the difficulty of explaining it to my peers or customers. I'm more concerned with the results they experience when they use the software.

> generic data-structure

What we call "go generics" has nothing to do with "typed go maps." To the extent that I've needed something "generic" up until they were formally introduced into the language careful interface design was enough to cover 90% of use cases. For the ones that weren't a map holding a function which wrapped a type-checked cast operation did the rest.

So all we're left with is the ability for the current go generics to automatically populate functions into your compiled image based upon instantiated and optionally constrained type usage rather than some explicit and planned mechanism implemented through interface.

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

#202

Post by Cthulhu_ »

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.

It's not yet an enterprise language; along the languages/frameworks, there's a huge ecosystem of QA, monitoring, security, etc solutions in the Java/.NET space that just isn't there in Go.

I mean there's a slow shift, I keep hearing of "rewriting a Java codebase to Go", but it'll be a slow process. And especially the bigger projects that represent 30 years of Java development will and should be reluctant to start rewriting things.

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

#203

Post by Cthulhu_ »

lopkeny12ko wrote: post #194
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…

> Unified codestyle The moment I got my first compile error due to an unused variable and an unused import, made me realize Go is not a serious programming language.

I wonder who hurt them, that is, how much did unused variables/imports hurt at Google for them to make those a compiler error?

Insofar I know it, I can imagine C/C++ caused some issues like that because it's hard to figure out whether an import is used, but an unused import does have a cost.

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

#204

Post by bborud »

dzonga wrote: post #71
tomcam wrote: post #5

IMHO Go has been one of the best-managed open source projects ever. Hats off to Google for supporting it.

I think this is a side effect of golang having failed at the mission to replace C++ or even Java, becoming a replacement for ruby / python etc for API's. makes the project's goals align with users not about conquering the world anymore. as that battle is lost to Rust, Zig etc.

I thought the mission was to replace C++ for a many things at Google. You can't really lose to someone you are not competing with. The choice of managed memory is a pretty obvious hint that Go isn't a general direct competitor to C/C++.

And neither Zig nor Rust have replaced C++ to any meaningful degree. Nearly everywhere it would count I still will have to deal with C++ for years, if not decades, to come.

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

#205

Post by valyala »

vyskocilm wrote: post #14
ainar-g wrote: post #2

Thank you, rsc, for all your work. Development in Go has become much more enjoyable in these 12 years: race detector, standardized error wrapping, modules, generics, toolchain updates, and so on. And while there are still things to be desired (sum types, better enum/range types, immutability, and non-nilness in my personal wishlist), Go is still the most enjoyable ecosystem I've ever developed in.

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

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

#206

Post by euroderf »

hgyjnbdet wrote: post #43

Out of interest, why are people so confident in Google when it comes to Go, yet every other day there's articles about how Google can't be trusted in related to Dart/Flutter which are soon to be abandoned?

I get an early-UNIX / Bell-Labs vibe from the entire Go project. New Jersey all the way. The ecosystem is too sleek and practical to abandon. My 0.02€, ymmv.

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

#207

Post by bborud »

purpleidea wrote: post #24
arp242 wrote: post #22

Earlier quoted context omitted.

> I'd also like to see less google control of the project. What does this even mean? Google basically just finances the project, but doesn't really "control" anything, never mind that "Google" isn't a monolithic entity in the first place.

They could be a non-google employee. They could let the community vote on who new leaders are, etc...

It is tempting to look at the election in the US and ask what will determine the outcome - who has the policies that will make peoples lives better or who can come up with the most effecive derogatory nickname for the opponent and stoke the most fear.

I've worked at Google, I've used Go for about 8 years at this point and I've met a few of the key Go figures at some point. I have to say that I have _no_ idea who would be best to run the project. And neither do you.

This isn't politics where the winner gets to vanquish their enemies and make themselves and their friends and family rich. It's developing and maintaining a programming language. The only real reward you'll get is admiration IFF you do a good job. Do a crap job and you ruin the project and/or become a pariah.

I would rather have those people who make up the core leadership tell me who should run the project since they not only know the technology, but they know the people and they know how to provide continuity. Continuity and discipline is all-important.

I'd prefer it if whoever runs the project works for Google since that is where Go was born. In part for continuity reasons and that Google has proven to be a very good home for Go, but also because it is good to have direct access to an organization that has resources to support you.

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

#208

Post by lenkite »

akira2501 wrote: post #201
lenkite wrote: post #172

Earlier quoted context omitted.

Please search/replace all `map[x][y]` in your Go projects with `map[sting]interface{}` in order to be honest and consistent with your opinion. And explain to all your stakeholders that you have done so because generics is bad. You have been using a generic data-structure since Go 1.0 but did not realize this.

> in order to be honest and consistent with your opinion Did you mean replace `map[string]string` with `map[string]interface{}`? You should take a look at Go's runtime map code. This is not a "generic" data structure. It's an unsafe data structure with some thin compiler sugar on top of it which is also something worth taking a look at. For example see how it handles something like `m["x"]` versus `m[12]` or a map us…

Apologies for the stupid typo. Anyways, I think we will need to simply agree to disagree because of this statement:

> I also write code based upon engineering principles and not on the difficulty of explaining it to my peers or customers.

I believe that difficulty of explaining code to "my peers or customers" is a basic engineering principle.

Also, I consider what the compiler does behind the scenes as irrelevant as long as you have reasonable performance and usability qualities. That's one of the fundamental principles of abstraction after all.

Btw, the inventor of the C programming language also said this. Dennis Ritchie -> "Code should be written for humans first, machines second"

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

#209

Post by kfgahs »

darby_nine wrote: post #84
anamexis wrote: post #70

Earlier quoted context omitted.

Linux/Linus Torvalds stands out as another notable BDFL.

I'm not intimate with Linux as a project, but this is an attractive argument for it. Unfortunately my main experiences with Torvalds are motivated by his chewing out people on mailing lists for something stupid they said rather than fending off varied interests, which makes him look far more petty than competent.

Linux started on Usenet, and that was the normal communication style. People simply did not take it seriously back then, it was understood to be partly humorous.

Linus doesn't even rant frequently either. People point to the same 10 messages over and over again.

He also tolerates when someone snaps back at him, unlike in projects with double standards like CPython where the old boys can do whatever they like but you are not allowed to criticize back or point out their numerous mistakes, segfaults, threading bugs and generally low code quality.

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

#210

Post by valyala »

nasretdinov wrote: post #38

Russ gave us proper vendoring and generics: two things I thought I'd never see in Go... Thanks a lot for the effort!

While vendoring is great, generics is bad addition to Go, since they complicated Go type system too much [1]. This makes typical Go code with generics hard to read and hard to maintain.

[1] https://go.dev/blog/type-inference

Post reply on HN