Russ Cox is stepping down as the Go tech lead • Hacker News Board

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

#361

Post by valyala » Sat, Aug 03, 2024, 10:52 AM UTC

jdnendjjd wrote: post #213

valyala wrote: post #205

Earlier quoted context omitted.

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

Go provides generic types since v1.0 - maps, slices and channels. Go also provides generic functions and operators for working with these types - append, copy, clear, delete. This allows writing clear and efficient code.

There is close to zero practical need in user-defined generic types and generic functions. Go 1.18 opened Pandora box of unnecessary complexity of Go specification and Go type system because of generics. Users started writing overcomplicated generic code instead of writing simple code solving the given concrete task.

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

#362

Post by valyala » Sat, Aug 03, 2024, 10:58 AM UTC

nasretdinov wrote: post #332

valyala wrote: post #205

Earlier quoted context omitted.

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

I'm not sure I can agree about generics. In many cases Go code is already fast enough, so other things come to play, especially type safety. Prior to generics I often had to write some quite complicated (and buggy) reflection code to do something I wanted (e.g. allow to pass functions that take a struct and return a struct+err to the web URL handlers, which would then get auto-JSONed). Generics allow to write similar…

> Prior to generics I often had to write some quite complicated (and buggy) reflection code to do something I wanted (e.g. allow to pass functions that take a struct and return a struct+err to the web URL handlers, which would then get auto-JSONed).

This sounds like a good application for Go interfaces (non-empty interfaces). The majority of generics Go code I've seen could be simplified by using non-empty interfaces without the need of generics.

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

#363

Post by valyala » Sat, Aug 03, 2024, 11:15 AM UTC

mseepgood wrote: post #259

makkes wrote: post #246

Earlier quoted context omitted.

s/syntax/API/ It's not that hard to understand what OP means.

It's just the visitor pattern, taught in software engineering 101. A function that takes a callback function that gets called for each visited value. Nothing strange about it. Many standard library functions such as sync.Map.Range or filepath.Walk have always used it. The new thing is that it now gets easier to use on the caller side.

The sync.Map.Range, filepath.Walk and other similar functions with visitor pattern in standard Go packages will remain there forever because of backwards compatibility. This means that new functions must be added to standard Go packages in order to be able to use them with iterators starting from Go 1.23. This complicates Go without reasonable benefit:

- You need to be able maintaining code with multiple ways to iterate over various collections in standard Go packages.

- You need to spend time on deciding which approach for iteration to use when you write new code.

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

#364

Post by daghamm » Sat, Aug 03, 2024, 11:58 AM UTC

sapiogram wrote: post #337

daghamm wrote: post #275

Earlier quoted context omitted.

"That's why go's toolchain isn't as messed up as npm, yarn, grunt, ..." And let's be honest, Rust toolchain is pretty messed up too. Want to cross-compile with go? Set the GOOS variable and you are done. On Rust you need to curl-sh rustup, switch to nightly, add new targets, add target to your cargo and cross fingers it works this week.

Rust cross-compilation isn't great, but this seems a bit hyperbolic: > On Rust you need to curl-sh rustup Yes, but you do that once per computer, probably when you installed the compiler > switch to nightly, No > add new targets, Fair. But this is also one-time setup. >add target to your cargo Not sure what you're talking about here tbh > and cross fingers it works this week. Don't use the nightly compiler and you're…

If you are doing embedded work, which is where you often do cross-compiling, you still need nightly.

But that's a whole different can of worms.

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

#365

Post by valyala » Sat, Aug 03, 2024, 1:02 PM UTC

valenterry wrote: post #260

segfaltnh wrote: post #114

Earlier quoted context omitted.

It's already quite popular. I'm less convinced there's a large pile of people wishing for a fairly high performance garbage collected language that are not using Go because of this. There just aren't many viable alternatives.

There are definitely lots, I'm one of them. I use Scala, which is very powerful and imho much nicer language than golang. But the tooling and other support is slow and subpar. But I just can't go back to a brain-dead language(!) like golang because it hurts to program in such languages to me. So I hope that either golang catches up with Scala's features, or that Scala catches up with golangs tooling. And I think ther…

Scala is overcomplicated esoteric programming language. It is great for obfuscation contests. It is awful for production code, since Scala code lacks maintainability, readability and simplicity properties.

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

#366

Post by jgowdy » Sat, Aug 03, 2024, 2:16 PM UTC

rsc wrote: post #318

jgowdy wrote: post #286

Earlier quoted context omitted.

Here are some citations since people seem to be just downvoting because they don't like the message: Go requiring non-ELF standard parameters for initialization of supposedly "C ABI" libraries, open since 2015. https://github.com/golang/go/issues/13492 The Go project specifically acknowledging the glibc-isms here: "All Linux first class ports are for systems using glibc only. Linux systems using other C libraries are…

If you just want to run Go programs on Alpine, it works fine. (I put some effort in back in Go 1.21 to make sure that the downloaded binary toolchains for Linux even work fine on Alpine.) If you want to use c-shared mode and dlopen, then yes that only works with glibc, but that mode barely works at all anyway. It's not actively supported at all.

Respectfully, these vague states of support between “active” and less active, “first class” and not first class, etc comes off as “we want to say we have that but shrug any time it’s deficient.”

Its similar to calling the port overall “linux/” rather than “linux//” which wouldn’t normally be called for except when you’re going to embed a bunch of a particular libc specific behavior in your consumption of libc.

Listening to Go advocates talk about C interop like it’s not only a solved problem but quite literally a strength of Go, while Go project leaders represent that support quite differently isn’t it. Perhaps clarification of these level of support terms and how the project embraces glibc specific behaviors unapologetically would help.

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

#367

Post by valenterry » Sat, Aug 03, 2024, 2:19 PM UTC

valyala wrote: post #365

valenterry wrote: post #260

Earlier quoted context omitted.

There are definitely lots, I'm one of them. I use Scala, which is very powerful and imho much nicer language than golang. But the tooling and other support is slow and subpar. But I just can't go back to a brain-dead language(!) like golang because it hurts to program in such languages to me. So I hope that either golang catches up with Scala's features, or that Scala catches up with golangs tooling. And I think ther…

Scala is overcomplicated esoteric programming language. It is great for obfuscation contests. It is awful for production code, since Scala code lacks maintainability, readability and simplicity properties.

I guess we have different opinions. Maybe you had some bad experiences in the past? Scala 3 is very different from Scala 2 many years ago

There are few languages that are safer and easier to maintain, imho. The typesafety is superb.

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

#368

Post by yencabulator » Sat, Aug 03, 2024, 2:40 PM UTC

unscaled wrote: post #358

yencabulator wrote: post #330

Earlier quoted context omitted.

Everyone just keeps repeating the same old gripe, without bothering to read the responses. Go needs a null-like thing because the language forces every type to have a zero value. To remove the concept of zero value from Go would be a major change.

The responses from Ian and the Go fans are not very well-thought. To begin with, zero values were never a great idea. It sounds better than what C does (undefined behavior), but zero values can also hide subtle bugs. The correct approach is to force values to always be initialized on declaration or make use-before-initialization an error. Having said that, it was probably too late to fix zero values by 2009, when Go…

If there's a non-nullable type, then there's types without zero values, and that means some basic properties of Go no longer hold. I don't know how many times that can be said differently. Whether something is in a struct or not is not relevant.

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

#369

Post by pansa2 » Sat, Aug 03, 2024, 2:54 PM UTC

pansa2 wrote: post #348

vbsd wrote: post #225

Earlier quoted context omitted.

Would you expand on the Python issue? I find recent Python additions either useful or non-intrusive, I wonder which ones you think are born out of FOMO.

The `match` statement is the most obvious - its motivation [0] is "pattern matching syntax is found in many languages" and "[it will] enable Python users to write cleaner, more readable code for [`if isinstance`]". But `if isinstance` is bad Python! [1] `match` also breaks fundamental Python principles [2] and interacts badly with the language's lack of block scope: >>> a, b = 1, 2 >>> match a: ... case b: pass ... >…

Here's Guido himself expressing FOMO about what would happen if Python stopped continually accumulating new features (specifically including the `match` statement):

> Essentially the language would stop evolving. I worry that that would make Python become the next legacy language rather than the language that everyone wants to use.

https://discuss.python.org/t/pep-8012-frequently-asked-quest...

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

#370

Post by euroderf » Sat, Aug 03, 2024, 4:07 PM UTC

fuzztester wrote: post #343

euroderf wrote: post #206

Earlier quoted context omitted.

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.

>New Jersey all the way New Jersey vs. what? I read about that phrase sometime earlier but forgot the rest of it. Is it vs. MIT / Stanford / West Coast / other? implying worse is better vs. other? is it also related to neat vs. scruffy approaches in AI? too much in tech to keep track of it all. but asking out of interest.

Well, it's kinda the whole "Worse is Better" thang. Flee from complexity.

As opposed to the "MIT style".

Related: Featuritis vs. YAGNI.