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.
Russ Cox is stepping down as the Go tech lead
251–260 of 396 posts
Re: Russ Cox is stepping down as the Go tech lead
#252Is 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…
Re: Russ Cox is stepping down as the Go tech lead
#253RSC 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.
Here is the first episode - devastating, convincing, easy to understand and very well written:
Re: Russ Cox is stepping down as the Go tech lead
#254Earlier 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).
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
#255Earlier 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.
Re: Russ Cox is stepping down as the Go tech lead
#256Earlier 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).
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
#257Earlier 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.
Re: Russ Cox is stepping down as the Go tech lead
#258Earlier 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:/…
Re: Russ Cox is stepping down as the Go tech lead
#259Earlier 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.
Re: Russ Cox is stepping down as the Go tech lead
#260Earlier 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.
And I think there are many similar people like me.