Live data from Hacker News

Russ Cox is stepping down as the Go tech lead

groups.google.com

251–260 of 396 posts

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

#251

Earlier quoted context omitted.

I don't think this is true. Python had a BDFL and it didn't seem to benefit much from it. I'm not sure what other projects this attitude draws from. Off-hand I'd guess it causes less drama but no appreciable increase of quality, just like other forms of bureaucracy. Meanwhile there's entire landfills of failed projects with single owners who couldn't bend enough. We just don't find this worth discussing. Of course th…

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

#252
post #130

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

golang's priority is "works inside of google" and everything else tends to be a bit of a fight

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

#253
post #49
post #18

RSC has a really good blog: https://research.swtch.com/

Incredible blog. I've said it on this site before, but his series on regular expressions is insanely high quality and the fact he just posted it there for all of us is a huge privilege.

Yes, I certainly benefitted very much from the series.

Here is the first episode - devastating, convincing, easy to understand and very well written:

https://swtch.com/~rsc/regexp/regexp1.html

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

#254
post #236

Earlier quoted context omitted.

Go doesn't really lend itself that much into code with a lot of abstraction layers. If you try to do that, you will start to run against the language. The more enterprisey software usually have lots of layers for organizational reasons, and go doesn't really fit there. So I don't think it will really be a hit in the enterprise. yes there are orm solutions and DI frameworks and all that, but they always feel like they…

> usually have lots of layers for organizational reasons The ridiculous number of layers in Java or C# are more of a skill and guidance issue than anything else. Older languages don’t always mean over-attempted-abstraction (think C, for example).

Never seen CORBA and COM written in C, I guess.

Enterprise Architects will do their beloved architectures with whatever languages are the tool of the day.

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

#255

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.

Thankfully, it is enough that it is a must in DevOps space.

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

#256
post #236

Earlier quoted context omitted.

Go doesn't really lend itself that much into code with a lot of abstraction layers. If you try to do that, you will start to run against the language. The more enterprisey software usually have lots of layers for organizational reasons, and go doesn't really fit there. So I don't think it will really be a hit in the enterprise. yes there are orm solutions and DI frameworks and all that, but they always feel like they…

> usually have lots of layers for organizational reasons The ridiculous number of layers in Java or C# are more of a skill and guidance issue than anything else. Older languages don’t always mean over-attempted-abstraction (think C, for example).

I have worked in enterprises and the layers are usually an organizational issue that just acts as code issue.

Structure of code often reflects structure of your company.

The code is often maze of layers because the company is a maze of sub-committees. Java/C# fits more neatly in there.

Although with Go, what can happen is that there is a maze of microservices. Maybe that's not that much better.

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

#257

Earlier quoted context omitted.

> or eschewing type safety Type casts are checked. > that doesn't have support for generics. We get first class functions and compiled closures with zero syntax overhead. It's entirely manageable. > or type safe because of a lack of generics. Case in point: sort.Slice(). It lacks ergonomics, otherwise, entirely usable. That being said, the generic version is faster and easier to use, so they are not without purpose,…

BTW this kind of thing is why I don’t use Go. Generics are a basic language feature for a statically typed language. Go needs a lot more features to be usable, like better error handling, but the ultra-conservative community that opposes any changes is a drag on the language and makes developing in it a miserable experience.

This is why I prefer Rust over Go. Go is far too simple.

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

#258
post #188

Earlier quoted context omitted.

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.

> I switched from C++ to C about 7 years ago and never looked back I'm definitely considering the same, and you're right - it's not C++ itself that appeals to me at all, it's the libraries. I'm not sure what C libraries I'd use for collections (instead of the STL and Abseil [0]), or in lieu of CLI11 [1] or Dear ImGui [2]. [0] https://abseil.io/about/design/swisstables [1] https://github.com/CLIUtils/CLI11 [2] https:/…

DearImgui’s coding style is a good compromise.

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

#259
post #246
post #217

Earlier quoted context omitted.

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.

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.

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

#260
post #101

Earlier 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

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 there are many similar people like me.

Post reply on HN