Earlier quoted context omitted.
Wow. I haven't followed Go for a while, thanks for that note. Iterators are very nice addition, even with typical Go fashion of quite ugly syntax.
Just last week I've implemented an iterator for my C++ type and lol to your comment. It was fucking nightmare compared to how you (will) implement an iterator in Go. I didn't study the reason why Go chose this way over others. I do know they've considered other ways of doing it and concluded this one is best, based on complex criteria. People who make value judgements like this typically ignore those complex consider…
Russ Cox is stepping down as the Go tech lead
281–290 of 396 posts
Re: Russ Cox is stepping down as the Go tech lead
#282Earlier quoted context omitted.
I’m sure if Go had nullable types and/or sum types from the beginning, it’s have been much more popular
Go has nullable types! We want non-nullable types!
Re: Russ Cox is stepping down as the Go tech lead
#283Thank 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.
Because of this change, Go 1.22 is actually the first Go version which seriously breaks Go 1 compatibility, even if the Go official doesn't admit the fact.
Re: Russ Cox is stepping down as the Go tech lead
#284Earlier quoted context omitted.
Here are some other projects that benefited from BDFLs in my opinion: * Keras * Ruby * Clojure * Zig * OCaml * Vim * Elixir I think all of these have ended up being unusually coherent. I may not agree with their design philosophy, but there clearly is one.
But php, one of the most notoriously chaotic mainstream languages, has a bdfl. And lua, arguably more disciplined than all of the ones you listed, has not.
Re: Russ Cox is stepping down as the Go tech lead
#285Earlier quoted context omitted.
Because Go has massive traction both inside and outside of Google, whereas Dart/Flutter never got big traction.
Dart only found a real good use case fairly recently. Given its explosion in usage since then, I think it may very well be more popular that go in several years.
Re: Russ Cox is stepping down as the Go tech lead
#286Is the new tech lead more likely to get rid of the glibc-isms that Golang won't let go of, like crashing if non-ELF standard parameters like env aren't passed in ELF library initialization, or maybe supporting global-dynamic thread local storage so we can dlopen() shared objects made in Go on platforms that don't hack like glibc? Go's obsession with glibc-isms is really unfortunate, and it's been many years. If you'r…
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 not fully supported and are not treated as first class."
https://go.dev/wiki/PortingPolicy
Go only supporting static-init thread local storage, and thus their "C ABI" libraries can only be dlopen()'ed if the libc pre-allocates memory to hack in libraries later.
Re: Russ Cox is stepping down as the Go tech lead
#287Earlier 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…
"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.
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 "analytics purposes"), or the worse way (doing brittle text replacement using weird git config stuff).
Or the annoying way of using a vanity import, and host that package in your domain with HTTPS using a wildcard certificate. But that would require either (1) only allowing access through WireGuard and hoping whatever reverse proxy you use has a plugin for your DNS registry; or (2) letting your VPS provider terminate DNS (e.g. Hetzner load balancer), but filter by IP address in your VPS firewall settings ensuring your public address (IPV4 /32 or IPV6 /64) is always up-to-date in the firewall.
Or using `replace` in `go.mod`, but these don't work transitively so these only work on "root" projects (i.e. they are ignored in dependencies), so I don't think this really counts as a solution.
I would have liked some way to force SSH access for a specific package, instead of HTTPS. Like for example `go.mod` supporting a `require-private` to use instead of `require` (or whatever similarly convenient directive for `go.mod` that implies authenticated SSH access is required).
Or in other words, say I have a package `github.com/_company/project`, and it depends on `github.com/_company/dependency`. I want to be able to do:
git clone 'git@github.com:_company/project.git' 'project'
cd 'project'
go mod tidy # Should just work.
`go mod tidy` should just work without complaining about `github.com/_company/dependency` not existing (because it's a private repository only accessible through SSH).(EDIT: Still, I'm agreeing with the point that Go's tooling is better than most other things I've tried. My only complains are this one about being inconvenient to use private repositories, and also that by default it leaks package names to Google whenever you do `go mod tidy`.)
Re: Russ Cox is stepping down as the Go tech lead
#288Earlier quoted context omitted.
Only those instances make the news. And then get repeated time and time again. It's a super-biased view not at all representative of his day-to-day behaviour. Also I've never seen Torvalds "chewing out people on mailing lists for something stupid they said", it's always been someone breaking something or something along those lines. That is: doing stupid. And it's also experienced maintainers Torvalds feels should ha…
> it's always been someone breaking something or something along those lines Not only is this a complete lie, but God forbid there's a process in place to catch these things instead of verbally abusing your coworkers for making mistakes, which Linus has done himself. > Imagine every outburst you have is public and pointed to for years to come You may be surprised to learn that the rest of us don't talk to anyone like…
You do. By outright claiming that I'm lying when I share what I've seen. Of course with no substance to back it up. Let me tell you: I've seen what I've seen. Have I seen an incomplete picture? Almost certainly. Am I wrong? Perhaps. Am I lying? No. Your post is extremely aggressive, pretty darn toxic, and explicitly the sort of stuff that's not appropriate here.
Do better next time. Doubly so if you want to get all high and mighty.
Re: Russ Cox is stepping down as the Go tech lead
#289Earlier quoted context omitted.
Almost zero drama and almost no feature creep or breaking changes. The team seems to have a focus, and does not change it easily. That is important for a programming language, and it doesn’t happen organically.
> almost zero drama Hm. Wasn't (the lack of) generics pretty drama filled? Especially the way they fought against it for so long.
Re: Russ Cox is stepping down as the Go tech lead
#290Earlier 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…