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

191–200 of 396 posts

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

#191

Post by _the_inflator »

cookiengineer wrote: post #158
hoten wrote: post #19

Earlier quoted context omitted.

What are some things that make it well managed?

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…

Clutter death that creeps in any language, as I see it. To this day, only a small subset of JS syntax is used; I cannot recall anyone besides me ever using method chaining like .map .filter, etc.

There is a reason why almost every good language is somewhat akin to C to this day, and maybe people started over to get rid of the noise.

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

#192

Post by gpderetta »

dash2 wrote: post #149
SatvikBeri wrote: post #113

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

Conversely, projects without clear leadership include rust (recently) and R, and I think they suffer for it. A very widespread system for organising people is to have a single responsible decision-maker, supported, monitored and advised by a committee. We see that through politics and business, and a lot of the best open source projects seem to do the same thing.

IMO C++ would have benefitted from having a BDFL for a bit longer as well.

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

#193

Post by noelwelsh »

randomdata wrote: post #180
edflsafoiewq wrote: post #171

Earlier quoted context omitted.

> An integer range is a very basic type, too Not really, its semantics get hairy almost instantly. Eg does it incrementing it produce a new range?

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 work on types, not on values. If 1..4 + 5..8 = 1..8 this has to happen at the type level, or, in other words, at compile-time.

Range types are very complicated types, compared to the types most people deal with.

Converting a string to an int is very simple to type (String => Int if you ignore errors) and adding integers is also simple to type ((Int, Int) => Int)

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

#194

Post by lopkeny12ko »

cookiengineer wrote: post #158
hoten wrote: post #19

Earlier quoted context omitted.

What are some things that make it well managed?

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.

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

#195

Post by noelwelsh »

p1necone wrote: post #98
LudwigNagasena wrote: post #87

Earlier quoted context omitted.

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

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.

Many people on here as well! :-) Reading the comments on this post is stepping into an alternative universe from the PL crowd I usually interact with. Very conservative. It's quite interesting.

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

#196

Post by mike_hearn »

randomdata wrote: post #157
hankman86 wrote: post #147

Does Google actually consider Go to be a success? I get the impression that it failed in what it set out to be: a successor to C/C++. Or put differently, Rust has eaten Go‘s lunch.

Go was never intended to be a C/C++ successor, it was intended to solve a class of problems that Pike and gang experienced in the software they worked on. Which is to say network servers. What you are probably remembering is that they assumed from their unique Google lens that it was C++ developers who had those same problems and would see it as an alternative to C++ when faced with those problems, but it turned out…

Well, a lot of servers are Google are (or were) written in Java not C++. As a GCd language, arguably Go competed with Java internally moreso than C++. One of Go's flagship projects (Kubernetes) started out being written in Java for example.

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

#197

Post by tommica »

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.

Why not? Pretty sure it's used in a lot of places, so it does seem quite serious if a language.

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

#198

Post by pansa2 »

serial_dev wrote: post #164
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…

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.

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

#199

Post by KronisLV »

wordofx wrote: post #179
cookiengineer wrote: post #169

Earlier quoted context omitted.

> ASP.NET or Spring (Disclaimer: I don't agree with HTMX rendering HTML chunks on the backend side, and I think that APIs should be HTTP-cacheable and use REST/JSON) Currently I am trying to get better at using Go with WebAssembly for the frontend. I love to use the webview/webview bindings to build local GUIs, but the need for redundant code in JavaScript for client data transfers and input data validation are annoy…

> and I think that APIs should be HTTP-cacheable Rendering html on the server does not make it not cacheable. The vast majority of people do not need graphql or shift their compute to the client with a junk react app with adhoc json endpoints everywhere.

I think server side rendering can often be pretty comfortable to use!

That said, I’ve also worked with JSF and PrimeFaces project and the ones I’ve seen have been more burdensome from a maintenance perspective and also more buggy than most SPAs that I’ve worked with.

I’ve also seen large monoliths where the tight coupling slows updates down a whole bunch, as opposed to the presentation being in a SPA that’s separate from an API that can be more limited in its scope (nothing wrong with using ASP.NET and Spring for just an API).

Heck, I’ve migrated a SPA from the now defunct AngularJS to Vue and it felt better than having a legacy project that’s stuck on an old version of Spring and PrimeFaces because there’s so many moving parts that when you try to update anything, everything breaks.

Plus, turning a SPA into a PWA is a fairly pleasant experience. I don’t think most folks need GraphQL though, especially when we can barely do RESTful API correctly and not even all places use OpenAPI specs and tooling, making client code impossible to generate (even SOAP did a better job in that particular regard with how widespread WSDL was).

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

#200

Post by Cthulhu_ »

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.

"Other languages have it" is a disease that's struck many languages in the past decade+, notably Javascript which added partial OOP support (classes but initially no access modifiers), or Java which added functional programming constructs via Streams.

I mean granted, Java needed some tweaks for developer ergonomics, and I'm glad they finally introduced value types for example, but I now find that adding entire paradigms to a language is a bad idea.

In the case of Go, yes it needed generics, but in practice people don't use generics that often, so thankfully it won't affect most people's codebases that much. But there's people advocating for adding more functional programming paradigms and syntax like a function shorthand, which is really frowned upon by others, because new syntax and paradigms adding to the things you need to know and understand when reading Go.

Plus at the moment / the way the language is designed, FP constructs do not have mechanical sympathy and are far slower than their iterative counterparts.

Post reply on HN