Live data from Hacker News

Russ Cox is stepping down as the Go tech lead

groups.google.com

321–330 of 396 posts

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

#321
post #216

Earlier quoted context omitted.

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 comm…

> It's impossible to write complex and performant programs without pointers. Well, I'd rather not copy around a multi-hundred-megabyte (or gigabyte) 3D object around to be able to poke its parts at will. I'll also rather not copy its parts millions of times a second. While not having pointers doesn't make impossible, it makes writing certain kinds of problems hard and cumbersome. Even programming languages which do n…

Well, looks like the GP missed a very common false fact:

The operations written in a program must literally represent the operations the computer will execute.

This one stops being true on high-level languages at the level of x86 assembly.

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

#322
post #27

rsc, thank you very much for all the hard work on the language that brought me into software engineering. Despite playing around with several programming languages, Go still feels like home. The development experience is terrific and I really appreciate how unapologetically simple and responsible the language and its creators have been. Good luck and all the best in all your endeavours!

> rsc, thank you very much for all the hard work on the language that brought me into software engineering. You're quite welcome, and thank you for this comment. I never expected when we started that Go would have such a positive impact on people's lives, bringing new people into programming and software engineering. That's definitely the impact I'm most proud of.

Thanks for helping the OEIS site stay alive. I was absolutely delighted by it the first time I visited it, decades ago. Equally delighted when I visited recently and saw some “Russ Cox” contributed.

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

#323
post #309
post #292

Earlier quoted context omitted.

Without pointers in some form or another, you can’t refer to allocated memory. You can change the name of pointers but they are still pointers.

It is possible to write complex and performant programs without allocating memory. And in some languages, where you only operate on values, and never worry about where something is stored, allocation is just an implementation detail.

> It is possible to write complex and performant programs without allocating memory.

I assume you mean by only allocating on the stack? Those are still allocations. It's just someone else doing it for you.

> And in some languages, where you only operate on values, and never worry about where something is stored, allocation is just an implementation detail.

Again, that's someone else deciding what to allocate where and how to handle the pointers etc. Don't get me wrong, I very much appreciate FP, as long as I do information processing, but alot of programming doesn't deal in abstract values but in actual memory, for example functional programming language compilers.

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

#324

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.

To be fair, with Go it's still painful to work with private repositories. And I'm invoking Cunningham's Law here when I say there's no convenient way to do so. If you want to use a private repository (let's say it's a private GitHub repository), then you either have to do it the bad way (setting up your own GOPROXY and setting it up securely, which implies also ensuring it's not leaking your source code elsewhere for…

[deleted]

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

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

I wish they would opt for ARC instead of a GC, to have a more deterministic memory objects lifecycle.

Other than that, I agree with your comment.

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

#326

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, conceptually

Just signed vs unsigned makes this a complex topic.

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

#327
post #217

Earlier quoted context omitted.

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.

Well, yes, that's the thing: you don't get any special syntax for generators (like "yield" keyword), which makes them look quite weird compared to other languages that have native support for them. You need to have very clunky and verbose syntax (at least I view it as such) which consists of having to define an extra nested closure and use a function pointer that was passed to you. Having a new keyword would allow for a much nicer looking generator functions, but that would break all existing tooling that doesn't yet support that keyword (and potentially break existing programs that use yield as a variable name or something like that).

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

#328

Earlier quoted context omitted.

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 re…

Plenty of people in the community considered dep way too messy to be the real solution.

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

#329
post #308
post #293

Earlier quoted context omitted.

Are there cases where people actually rely on the previous behavior? I always assumed that it was considered faulty to do so.

There were certainly buggy tests that relied on the old behavior. We didn't find any actual code that relied _correctly_ on the old behavior. https://go.dev/wiki/LoopvarExperiment

Love it, even though it must have been incredibly confusing when old tests failed at first. The assumption being that the tests were correct. They _passed_ all those months or years!

I'm just also watching your YT video on testing and enjoying it very much!

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

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

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

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.

Post reply on HN