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

221–230 of 396 posts

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

#221

Post by lnggahc »

ahoka wrote: post #216
thayne wrote: post #122

Earlier quoted context omitted.

Wow, that's painful to read. Separating the concept of pointers and nullable types is one of the things that I think go having from the beginning would have made it a much better language. Generics and sum types are a couple of others.

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

Well, clearly there is a need for a special value that is not part of the set of legal values. Things like std::optional etc. are of course less performant.

If I can dream, all of this would be solved by 72-bit CPUs, which would be the same as 64-bit CPUs, but the upper 8 bits can be used for garbage collection tags, sentinel values, option types etc.

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

#222

Post by dwattttt »

lnggahc wrote: post #221
ahoka wrote: 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 null. Well, clearly there is a need for a special value that is not part of the set of legal values. Things like std::optional etc. are of course less performant. If I can dream, all of this would be solved by 72-bit CPUs, which would be the same as 64-bit CPUs, but the upper 8 bits can be used for garbage collection tags, sentinel values, option type…

> If I can dream, all of this would be solved by 72-bit CPUs, which would be the same as 64-bit CPUs, but the upper 8 bits can be used for garbage collection tags, sentinel values, option types etc.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri...

Address space is 64bit, pointers are 128bit, and encode the region the pointer is allowed to dereference. And there's a secret 129th bit that doesn't live in the address space that gets flipped if the pointer is overwritten (unless it's an explicit instruction for changing a pointer)

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

#223

Post by lioeters »

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.

The moment you see that you had misspelled a variable name by a single character when the compiler warned you about an unused variable, you'll realize Go is a serious programming language.

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

#224

Post by dwattttt »

skybrian wrote: post #119
p1necone wrote: post #98

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.

I regularly find quite smart people assume Rust's references must be fat pointers to handle lifetimes, and check them all at runtime.

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

#225

Post by vbsd »

pansa2 wrote: post #198
serial_dev wrote: post #164

Earlier quoted context omitted.

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…

> pointless features are added because maintainers are afraid I wouldn't have described language designers' feelings that way, but you're absolutely right. For example, witness the recent features added to Python with little more justification than "other languages have it". It's pure FOMO - fear of missing out.

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.

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

#227

Post by pwdisswordfishz »

ahoka wrote: post #216
thayne wrote: post #122

Earlier quoted context omitted.

Wow, that's painful to read. Separating the concept of pointers and nullable types is one of the things that I think go having from the beginning would have made it a much better language. Generics and sum types are a couple of others.

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…

Every type must have some sort of a default value. (A generalization of the first item, really.)

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

#228

Post by sirsinsalot »

ahoka wrote: post #216
thayne wrote: post #122

Earlier quoted context omitted.

Wow, that's painful to read. Separating the concept of pointers and nullable types is one of the things that I think go having from the beginning would have made it a much better language. Generics and sum types are a couple of others.

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…

Never met a programmer that thought these things were true.

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

#229

Post by foldr »

noelwelsh wrote: post #193
randomdata wrote: post #180

Earlier quoted context omitted.

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

I think you're confusing the type and value level. The original statement was about a range type , that is something like an integer that is statically constrained to a range of, say, 1..4 (1, 2, 3, 4). To work with this as a type you need to have type level operations, such as adding two ranges (which can yield a disjoint range!), adding elements to the range, and so on, which produce new types. These all have to wo…

OP is just saying that you don't have to permit operations such as addition or incrementation on range types, in which case you don't need the corresponding type-level operations.

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

#230

Post by foldr »

sharno wrote: post #101
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.

I’m sure if Go had nullable types and/or sum types from the beginning, it’s have been much more popular

Perhaps, but other languages that look a lot like Go with these additions (e.g. OCaml) have not gained much popularity, despite getting much more love on forums like HN. It's important to remember that the people expressing strong opinions about sum types on the internet are a tiny and non-representative fraction of working programmers.
Post reply on HN