Live data from Hacker News

Russ Cox is stepping down as the Go tech lead

groups.google.com

171–180 of 396 posts

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

#171

Earlier quoted context omitted.

Wow, that discussion is infuriating. I'm shocked that many people on there don't seem to understand the difference between compile time checks and runtime checks, or the very basics of type systems.

I think people do understand the basics of static type systems, but disagree about which types are essential in a "system language" (whatever that is). An integer range is a very basic type, too, conceptually, but many languages don't support them in the type system. You get an unsigned int type if you're lucky.

> An integer range is a very basic type, too

Not really, its semantics get hairy almost instantly. Eg does it incrementing it produce a new range?

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

#172

Earlier quoted context omitted.

BTW this kind of thing is why I don’t use Go. Generics are a basic language feature for a statically typed language. Go needs a lot more features to be usable, like better error handling, but the ultra-conservative community that opposes any changes is a drag on the language and makes developing in it a miserable experience.

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

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

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

Nomination for RSC's greatest technical contribution: module versioning. Absolutely fundamental to the language ecosystem. https://research.swtch.com/vgo-intro

The interesting thing is - this went pretty much against the community at the time.

At the time, the community seemed to have settled on dep - a different, more npm-like way of locking dependencies.

rsc said "nope this doesn't work" and made his own, better version. And there was some wailing and gnashing of teeth, but also a lot of rejoicing.

That makes me a bit sad that rsc is leaving.

On the other hand, I don't really like the recent iterator changes, so maybe it's all good.

Btw if you reading this rsc, thanks a lot for everything, go really changed my life (for the better).

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

#174

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.

Go doesn't really lend itself that much into code with a lot of abstraction layers. If you try to do that, you will start to run against the language.

The more enterprisey software usually have lots of layers for organizational reasons, and go doesn't really fit there. So I don't think it will really be a hit in the enterprise.

yes there are orm solutions and DI frameworks and all that, but they always feel like they don't belong in the language.

(Also, java and .net and php are much older and have much bigger enterprisey ecosystem.)

I have seen go replacing the php stack though, and in some way the "original" python stack - but python now has ML.

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

#175
post #124

Earlier quoted context omitted.

> Some languages do better than others at saying no, and those languages tend to be the ones that achieve widespread adoption. Unfortunately that’s not at all true - Go is a real outlier here. If it were true, we’d all be writing C instead of C++, Lua instead of Python and ES5 instead of TypeScript.

The choice is yours. Don't blame your choices on other people's opinion that you don't agree with. Everything in life is a tradeoff. If you don't agree with the available languages, make it better. That's the power of open source :)

> The choice is yours [pansa2].

Who gave him control over what sees widespread adoption?

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

#176

Does Google actually consider Go to be a success? I get the impression that it failed in what it set out to be: a successor to C/C++. Or put differently, Rust has eaten Go‘s lunch.

One guy that did ML in Google told me that Google indeed tried to use Go for ML problems, then realized it's too slow and went back to C++ there.

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

#177
post #145

Earlier quoted context omitted.

Java and C# being the obvious (and more performant) alternatives. And compared to them, Go already wins because of not being, well, "enterprisey". And with that I mean less the languages itself, but also the whole ecosystem around them.

Go's is already "enterprisey" enough, thanks to Kubernetes ecosystem.

For the 3 people who actually need Kubernetes.

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

#178

Earlier quoted context omitted.

> or eschewing type safety Type casts are checked. > that doesn't have support for generics. We get first class functions and compiled closures with zero syntax overhead. It's entirely manageable. > or type safe because of a lack of generics. Case in point: sort.Slice(). It lacks ergonomics, otherwise, entirely usable. That being said, the generic version is faster and easier to use, so they are not without purpose,…

BTW this kind of thing is why I don’t use Go. Generics are a basic language feature for a statically typed language. Go needs a lot more features to be usable, like better error handling, but the ultra-conservative community that opposes any changes is a drag on the language and makes developing in it a miserable experience.

error handling is what I like about go.

ok errors.As is a little stupid, I'll give you that. But that's all.

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

#179

Earlier quoted context omitted.

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.

> ASP.NET or Spring (Disclaimer: I don't agree with HTMX rendering HTML chunks on the backend side, and I think that APIs should be HTTP-cacheable and use REST/JSON) Currently I am trying to get better at using Go with WebAssembly for the frontend. I love to use the webview/webview bindings to build local GUIs, but the need for redundant code in JavaScript for client data transfers and input data validation are annoy…

> and I think that APIs should be HTTP-cacheable

Rendering html on the server does not make it not cacheable.

The vast majority of people do not need graphql or shift their compute to the client with a junk react app with adhoc json endpoints everywhere.

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

#180

Earlier quoted context omitted.

I think people do understand the basics of static type systems, but disagree about which types are essential in a "system language" (whatever that is). An integer range is a very basic type, too, conceptually, but many languages don't support them in the type system. You get an unsigned int type if you're lucky.

> An integer range is a very basic type, too Not really, its semantics get hairy almost instantly. Eg does it incrementing it produce a new range?

The semantics are always complex. The same type of question arises for all basic types. For example, what does adding a string to an integer produce?

Or do you give up on answering that and simply prevent adding strings and integers? When one wants to add them they can first manually apply an appropriate type conversion.

That is certainly a valid way to address your question – i.e. don't allow incrementing said type. Force converting it to a type that supports incrementing, and then from that the developer can, if they so choose, convert it back to an appropriate range type, including the original range type if suitable.

Of course, different languages will have different opinions about what is the "right" answer to these questions.

Post reply on HN