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

161–170 of 396 posts

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

#161

Post by flohofwoe »

pansa2 wrote: post #124
lolinder wrote: post #96

Earlier quoted context omitted.

Yes. And? Programming languages more than almost any other type of project end up swamped with thousands of competing requests to implement mutually incompatible features. Some languages do better than others at saying no, and those languages tend to be the ones that achieve widespread adoption.

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

FWIW I switched from C++ to C about 7 years ago and never looked back (can't quite escape C++ completely though because some important libraries are still written in C++ unfortunately). I vastly prefer TS to JS, Python and Lua though.

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

#164

Post by serial_dev »

cookiengineer wrote: post #158
hoten wrote: post #19

Earlier quoted context omitted.

What are some things that make it well managed?

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 take it or leave it, but you won't tell us how to run this project"

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

#166

Post by KronisLV »

cookiengineer wrote: post #158
hoten wrote: post #19

Earlier quoted context omitted.

What are some things that make it well managed?

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.

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

#167

Post by randomdata »

bitpush wrote: post #59
patmorgan23 wrote: post #54

Earlier quoted context omitted.

Off the top of your head, name 3 projects/apps that use Dart/Flutter, now do the same for go.

If you cant name 3 projects/app that use Dart/Flutter that just shows your bias. Can you name 3 apps/projects that use COBOL? -- This is akin to asking, "Quick, name 3 books written in Persian. Huh, you cant name them? Must be a dead language"

> Can you name 3 apps/projects that use COBOL?

Does this imply that you see COBOL as having a trustworthy future, making it a great choice for a new greenfield application?

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

#168

Post by randomdata »

cocok wrote: post #156
amiga386 wrote: post #94

thanksStr := "thank you rsc" ret, err := sayThanks(thanksStr) if err != nil { return nil, err } return ret, nil

Can anyone familiar with Go explain why not return sayThanks(thanksStr) I've seen this "if err != nil" pattern before, but I can't help thinking that it's not necessary. "return ret, nil" ignores err's value, which is nil anyway. "return nil, err" ignores ret's value, but why? If the caller checks for err before doing anything with ret, it doesn't hurt having ret always passed up. 4 extra lines only to lose the value…

It's a joke about how every contrived Go example posted to the internet is in that vein. You wouldn't blindly pass something up the stack like that in a real application. Well, maybe if you hate other developers for some reason.

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

#169

Post by cookiengineer »

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.

> 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 annoying me a bit much.

I am trying to find out a paradigm that could benefit from the strength of JSON marshalling, with the idea that you can map routes to structs, for example, and where a unified "Validate() (bool, error)" method as an interface is enough to use the same structs on both the frontend and backend, for both serialization and validation/sanitization.

Having said that, I think that what's missing the most in go right now is a good UI framework for the web, but it's hard to find a paradigm that fits nicely into the language while also being able to handle dynamic data/refreshes/render loops without getting too bloated too quickly.

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

#170

Post by jrimbault »

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

It's like they don't speak the same languages.
Post reply on HN