> highly performant lightweight threads with full blocking semantics via goroutines

If you've ever tried to doing any actual high-performance work using the Go mantra "share by communicating" with channels, you'll quickly find that it isn't high performance. Any Go program that actually needs high performance will break all the rules for thee and use undocumented things like sync/atomic.

I have not once had to use sync/atomic and I wrote and maintain a massive data aggregation and quantitative algorithm platform 100% in Go at work.

Channels in Go are not a function, they are a primitive type.

In contrast to semaphores aka. mutexes, channels are highly recommended since, when used correctly, they can serialize concurrent access very efficiently. Take care of how to use them - do not pass tiny amounts of work over channels, pass around a chunk of work and work in batches.

Normally the work you will do per item will greatly exceed the 90–250 ns it takes to move the item through the channel, so it’s just not worth worrying about.

Channels are slower than copy() for just shifting bytes, but in a simple scenario are about as fast as a naive self-made channel implementation using the sync package.

The choice of channels vs. mutexes is one of design, not implementation. BOTH use LOCK XCHG and pay the price.

Also, channels are blocking data structures. APIs should be designed synchronously, and the callers should orchestrate concurrency if they choose. If you just want to synchronize access to shared memory then use a mutex. These are not good use-cases for channels to begin with.

As they say: Share memory by communicating, rather than communicating by sharing memory.

An easy example of this: Use a channel with a buffer of 1 to store the current number, fetch it from the channel when you need it, change it at will, then put it back for others to use.

That last example, where you store a single number in a channel, seems to contradict your recommendation to "not pass tiny amounts of work over channels?"

It's supposed to be an easy example of the concept of sharing memory by communicating and has nothing to do with the recommendation to not pass tiny amounts of tasks.

Interestingly, even though Go is most popular for writing web services and promotes channels, we almost never use channels in our microservices written in Go because they are not persistable. If you care about not losing your data on power loss or a panic, your work queues have to be persistable and retriable. Channels IIRC are just in-memory queues with mutexes under the hood and provide nothing of that. We only use them for a few tricks/hacks like listening to signals to safely stop goroutines.

That makes sense: channels are a way of organizing concurrent programs, not a way of organizing distributed systems. They're a tool you might use to build a persistent work queue (or, like many programmers, including people working on the Go stdlib, you might use other synchronization constructions), not a work queue themselves.

When I first learned Go, my impression (and also tutorials usually imply that) was that they are a nice elegant way to build concurrent pipelines where goroutine A sends work items to goroutine B which can, in its turn, send some work items to goroutine C etc. But in practice for robustness we prefer persistent queues for such pipelines because on power loss, a panic, or if your application is simply being killed on redeploy, your program can lose data or end up in an inconsistent state, because whatever was the in the channels is completely lost (and the work is already half done). So it leaves us with only a few use cases where they're really useful such as basic goroutine coordination. I think what you are saying is that they're a synchronization primitive akin to mutexes, atomics etc., no more no less, and I'm fine with that, but then it's not clear why then channels have a special syntax and why they are sold as one of Go's strong points, if it's just a niche synchronization primitive. The only useful case I found for them was to send an empty struct to a goroutine to signalize that there's a new work item in the persistent queue, to avoid having to poll the external queue too often. I wonder if other web devs have experience similar to ours, or maybe there are other use cases for channels we are not aware of.

The point of channels is to have communication between threads that's easier to reason about than explicit locks. Rather than, for instance, unlocking a map to update it, you treat a single thread as a "server" for that map. If you don't want to structure your programs that way, you'd just use mutexes.

In older web languages, like PHP, I would reckon it’s like making a self-http call where you don’t care about the result and just want to trigger some work elsewhere in the application async. I guess with Go channels, you’d lose out on concurrency, automatic retries (depending on infra), and debuggability — you could do the same with Go and http calls though and just drop the channels completely.

But yeah, sometimes things break. We rely on things like nginx options to retry GET requests and idempotency in the design; failing gracefully (via a shutdown callback to always return something to a caller); ensuring work is completed before writing a successful response anywhere, along with being idempotent; and, ensuring there’s observability in every long-running task.

> That makes sense: channels are a way of organizing concurrent programs, not a way of organizing distributed systems.

Exactly.

Nit: sync/atomic is not undocumented: https://pkg.go.dev/sync/[email protected]

What makes you think sync/atomic is undocumented? https://pkg.go.dev/sync/atomic

The documentation says

> Package atomic provides low-level atomic memory primitives useful for implementing synchronization algorithms.

> These functions require great care to be used correctly. Except for special, low-level applications, synchronization is better done with channels or the facilities of the sync package. Share memory by communicating; don't communicate by sharing memory.

There was a long mailing list discussion discussing use cases and certain desired behaviours that the people on the list agreed upon. In the end they chose not to make those behaviours explicit and leave it somewhat open-ended and instead put in the phrase "great care" to cover it off, rather than define it.

Do you have a link? Curious about the use cases

I can't find the original thread that had a specific example of a sequence of instructions where the desired/actual result wouldn't be guaranteed by the documented behaviours, but was decided to leave it as-is. The closest I can find[0] is lacking specifics, though does say somewhere that better docs would be nice. And the 'great care' warning/disclaimer is still in the docs.

I found it while using sync.atomic to make some implementation faster, then wanted to know exactly what the language/runtime behaviour/guarantees were and was surprised but not shocked to find the 'for the go authors but not thee' attitude of the conclusion. It did have some reasonable founding where they mentioned that by formally defining it, it could be over-specified precluding future optimizations on even newer processors/architectures.

I would have preferred if the documentation explicitly listed the parts that are not fully defined with reasons for doing so given. That's better than a generic danger signpost. The irony here is that Go was supposed to be not-Java but has the same 'for mainstream' mindset rather than being the sharp tools for the sharp developers.

[0] https://groups.google.com/g/golang-nuts/c/0uPDCRiBWqc

I was gonna answer:

"Channel ops are wait free if the buffer has extra space though, so that should be fast"

But, I looked it up and channels indeed use locks even in case of buffered ops. Sigh. I guess MPMC with scheduler yield isn't the easiest thing to write and maintain.

Unless you're using something like an RCU queue, you're still going to have to lock operations around moving the queue pointers, or you could have producers writing over each other or writing into a slot a consumer has already read from.

I don’t think channels were ever billed as peak performance abstractions. I certainly don’t use them as often as I use mutexes or atomically for parallel code, but frankly I rarely write parallel code in the first place because it’s harder to maintain and I rarely need the performance (single threaded Go is really performant already compared to other languages in its class).

Heh. For the past 3-ish years I operate a flock of microservices in Go. I don't really write the code, but do quite a bit of reading to debug and fix stuff. This month I've seen a channel in production code. I did a double take and took my time to reflect on the language.

> I don't think it focused enough on the positives (of which I think there is some - for example, it has very nice and highly performant lightweight threads with full blocking semantics via goroutines).

I've tried to focus on things that I ran into. I haven't had the chance to write a lot of concurrent code in Go, that's why I didn't comment on this aspect. Most of the code I've been working on has been serial, with concurrency and parallelism managed at a different layer than the one I was working on.

That said, the same point applies for a bunch of negative points that you may seen in other articles criticizing Go. I didn't mention them because I didn't run into them in practice.

> I think I would say overall that I like the idea of Go better than I like Go itself. I like the idea of a simple language, but not the choices they made. I like the idea of simple tooling, but don't find their tooling simple to use

I think I just had a revelation moment. This is exactly how I feel about Go. I keep trying to use it for side projects and I think I'm lying to myself... It's not Go what I like, but the idea of it.

so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more expressive', etc.

I've heard they're great languages (haven't used them much myself), but I probably wouldn't choose them for say an early-stage startup. Go's value is in being a mundane, repetitive, boring language. It makes it easy for any random kid to dive into an existing code base and become productive, that can be super valuable.

There's a theoretical gradient of programming languages where one side is "has a single expression for exactly your problem, a single unique expression you've never heard of exists to solve every possible problem" and the other is "requires thousands of expressions to express your problem, but only a thousand are available" - or something like that.

My point? There's no perfect language, yet people are always trying to find one. It's OK if you don't like Go and prefer another language, the real devil / tradeoff is in the fact that conformance to a single language (or set of languages) is such a strong social phenomena. I think that's why people end up so angry with viewed-as-subpar languages like Go gaining so much traction: it limits personal choice of which language to work in.

I'm positive linguists aren't happy with English becoming the global language either, but you've gotta admit - having a global language is valuable.

> I'm positive linguists aren't happy with English becoming the global language either

Nit: Linguists do not hold prescriptive opinions about the "quality" of languages. They analyze languages to form descriptive theories about the structures and features of certain languages. I only nitpick this because, while having a lingua franca is certainly valuable and there is nothing "bad" about English any more than literally any other language, the closest thing to this in programming "languages"/notations is actually C, not Go. It's hard to overstate the invisible influence on C on basically every mainstream language and how we think of programming and computers in general.

An interesting analogue to your example of English is the varying efforts to transliterate most languages into using the Latin alphabet, much like how many programming languages today need/greatly benefit from a compatibility layer with a C compiler/the C standard library.

> There's no perfect language, yet people are always trying to find one. It's OK if you don't like Go and prefer another language, the real devil / tradeoff is in the fact that conformance to a single language (or set of languages) is such a strong social phenomena. I think that's why people end up so angry with viewed-as-subpar languages like Go gaining so much traction

I hope my post didn't come across this way. To be clear, I think Rust and Swift (as two examples that I mention multiple times) have a lot of problems (slow compilation being a very big one), and are by no means perfect. I'm not angry at Go's popularity as much as wanting improvements to the developer experience.

An F# program can be about as mundane as a similar Go program, only concise.

This is like the C++ argument that you should just use C++ because it has almost every feature so you can just use the ones you want and ignore the others. Of course, in practice you still have to deal with colleagues and upstream packages that use features you don’t like. Same deal with F#—you could write F# in a Go-like style, but you’ll be swimming against the current. And the only advantage is a little less verbosity, which really isn’t anyone’s bottleneck—people over-index on minimizing localized boilerplate and ignore the costs of gratuitous abstraction.

Type-inference is a zero-cost 'abstraction' and any place you choose can make explicit narrowing of them. The libraries I needed to make a web application didn't have any mind-bending patterns, but rather did the most obvious things with the basic language features.

Scala and Haskell are pretty much "dead" language, I worked with Scala in the past, it was impossible to find poeple willing to work with it so everything was re-written in Java.

Im not sure its fair to call Scala dead. Its still pretty widely used, at least in companies in London. Hiring is a bit more competitive but we still get some great Scala devs interviewing for the more senior roles.

Disclaimer - I work with Scala every day, so am definitely highly biased.

I worked at a Scala shop about 10 years ago. Everyone had their own preferred "dialect", kind of like C++, resulting in too much whining and complaining during code reviews. IMHO, the language is too complex. Also, the compiler was slow, and the IDE support was plain awful (Eclipse was especially bad, IntelliJ was better.) Keep in mind this was over a decade now, so I'm sure things have improved.

This was my experience as well. I worked at a place that used Scala primarily in the "better Java" style and enjoyed the language a lot. I moved to a different company and the lead programmer there was a functional purist who insisted on putting scalaz/cats into everything and using Scala as Haskell lite, despite it really not being appropriate for the use case. It really soured me on the language.

There’s no bigger productivity killer than scalac and sbt.

I work in a Scala shop with 500k lines of Scala. We're moving to a Bazel-based development workflow because SBT is a slog and doesn't handle incremental compilation well at all.

Is it still that way? I've thought about taking another look at it for personal projects.

By the time the sbt shell starts I swear to god maven would have my project fully packaged.

Not parent but yes it is.

Scala is definitely not dead. Sounds like a recruiting failure than anything about the language itself.

I learned Scala a while ago on the job, and I’m grateful for that opportunity. Nobody on your team volunteered?

Lol. Why would people be unwilling to work in Scala. I moved from Java to Scala and it was a breath of fresh air. We’ve had no trouble hiring people who didn’t know Scala but learned it on the job. It’s not rocket science.

Scala just got a new version, which fixes plenty of shortcomings. It also has an option to exclude the null value from the language, so I wouldn’t call it dead by any mean of the word.

It is also running splendidly at plenty of companies.

I bet plenty of universities will keep using them beyond our lifetimes.

From that point of view they are doing quite well.

you can also take a Latin course in college. how "well" is Latin doing?

Good, it is still the official language in Vatican documents, has an updated dictionary, and some European countries see it as a CV requirement by most HR departments when hiring for top management positions.

> some European countries see it as a CV requirement by most HR departments when hiring for top management positions.

This sounds utterly bizarre, I have a very hard time believing this. Which countries would that be?

I can't confirm the specific example, but this sounds like a smoke cover for nepotism and/or classism. If you're not allowed to recruit solely from your personal friend group, requiring that applicants be able to speak a dead language let's you select that same group of people while giving a flimsy justification.

So, just like strong idiosyncratic preferences for particular programming languages.

In France for example, it used to be that all good family kids studied Latin, so high league universities and was seen as plus on the CV, at least for 20 years when I used to live there.

France would be a typical example, except that this is an urban legend.

Context: I graduated from the 3rd best high school in France, then from one of the Grandes Ecoles (~ Ivy League). I was born in the early 70's in Versailles.

German and Latin were seen as languages where the best students meet. This was a vision of the parents without getting in the reality. The best high-school students were everywhere.

I had Latin and Greek in mid-school and high school like anybody else. Complete loss of time when you are not interested.

At university it did not matter at all.

Today, when recruiting even for the "really French" companies nobody would think about Latin as a discriminant. It literally wouldn't cross anyone's mind.

There are urban legends everywhere, this is one about French education (which is sometimes great, and sometimes completely backwards to the point where I doubt the decisions makers have ever seen kids in real life)

As for today (and not 40 years ago), in the class of my son in that same elitist high school, one student does Latin and Greek. Because he is interested in the languages.

That’s pretty good for a dead language, but not so much for a living one to the OP’s point.

> so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more expressive', etc.

I don't think Haskell composes that well; monads don't combine well (not that I could do better) since you can only stick them together in an ordered way, the lazy evaluation makes it complicated to see how your program will run by reading the code, and so on.

Btw, "sum types" means enums; it's not actually a super-complicated Haskell only feature.

Do you write imperative programs that execute statements — out of order? Ordering is precisely the point of monads, since they are monoids as well.

And sum types are most definitely not enums, though Rust’s enums do use a bit strange terminology here.

> Do you write imperative programs that execute statements — out of order? Ordering is precisely the point of monads, since they are monoids as well.

Sure do. After all, your superscalar CPU executes things out of order, and C is a pure functional language in the memory monad.

http://conal.net/blog/posts/the-c-language-is-purely-functio...

> And sum types are most definitely not enums, though Rust’s enums do use a bit strange terminology here.

Swift's enums too. But sure, in C it's an enum with a union at the end.

Well, being pedantic, sure almost every modern CPU uses OOE. But they must do so with the huge caveat that from the outside it should be equivalent to executing it in serial (notwithstanding CPU vulnerabilities). But this is an implementation detail only, we could just as well use an older CPU design.

Having written a lot of Scala, I generally agree until you can form a team that knows what they're doing or has a background in Scala. After that, Scala shines as the codebase(s) scale.

Substitute Scala for any other programming language and the statement still holds.

Experienced developers and those with specific language expertise excel when implementing in that language.

Who would have expected that? /s

The point is the barrier to entry for Scala is higher but once you have a skilled team working in Scala, you probably get more velocity than others due to the language ergonomics.

I don't think there are any (many?) studies on this subject. Much less that confirm this particular bias you've shown.

> mundane, repetitive, boring language

These apply just as well to assembly, yet they are the reasons almost nobody tries to use it.

> so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more expressive', etc.

I wrote Scala for years - it might be a bit too complicated but overall pretty decent, but I hear good things about Scala 3. I think the ML's, of which it takes inspiration from, are probably a better match. OCaml (EDIT: or F# as another comment mentioned) for instance is a pretty nice balance.

Haskell is very nice and I think qualifies except that it is pretty hard core purely functional with no punches pulled (unlike ML), so is foreign enough for most people not to be deemed a candidate.

I like Rust probably best atm as it is "imperative but with a functional flair", but doesn't qualify as easy I don't think, but is definitely highly logical and composes very well (even if obviously not finished yet).

> I've heard they're great languages (haven't used them much myself), but I probably wouldn't choose them for say an early-stage startup. Go's value is in being a mundane, repetitive, boring language. It makes it easy for any random kid to dive into an existing code base and become productive, that can be super valuable.

I would probably agree on the novice programmer and picking up Go quickly which is arguably the prime feature of Go. I just question the quality of that code, and honestly, don't feel Go is nearly as easy as touted. It is simple for sure, but not always easy. I always had to look up simple things like those magic comment compiler directives and is that interface{} param a pointer or a pointer to a pointer? I just remember the lack of expressiveness actually causing real world confusion (for me at least).

> There's a gradient of programming languages where one side is "has a single expression for exactly your problem, a single unique expression you've never heard of exists to solve every possible problem" and the other is "requires thousands of expressions to express your problem, but only a thousand are available" - or something like that.

While true, I would argue we have found a small amount of constructs that fit well 80% of the time, and is demonstrability better than half the constructs that fit well 40% of the time. Trying to solve every problem with a new construct is not worth it, but nor is the opposite extreme IMO.

> My point? There's no perfect language, yet people are always trying to find one. It's OK if you don't like Go and prefer another language. A real devil / tradeoff is the prohibition of using languages that do not conform with past (company) choices.

Honestly not sure we've found the ideal language yet, and agree there is subjectivity and trade offs at about every turn. In fact, the only thing I'm certain of is that Go missed what I would look for in just about every category except a few (but I agree it is easy to learn, but does it matter if you can't write good code with it?). That said, very intelligent and respected people disagree with me, so to each their own.

> I like Rust probably... (even if obviously not finished yet).

what? what languages fit your definition of finished?

My disappointment with Rust, that in no way diminishes how much I enjoy using it in my own time, is that I have a hard time recommending it for microservices, which are arguably an average project at an average company. The ecosystem just doesn't feel as fleshed out or complete as in Go. It's a shame because there's libraries in Rust that I adore like clap, serde, and diesel but when I last wanted to write something that integrates with AWS, I found a deprecated unofficial crate and a non-production-ready official crate from AWS.

I don't know whether to attribute this disappointment to the breadth of what Rust can be used for and the difficulty in doing all of them well, or a lack of wider/corporate buy-in for these use cases. It's a pity, because after getting past the initial learning curve I struggle to find anything wrong with the language itself.

FWIW, AWS now have an official SDK for Rust in beta:

https://aws.amazon.com/sdk-for-rust/

There are people at Microsoft working on a Rust SDK for Azure, but it's explicitly a volunteer effort with no support guarantees at the moment:

https://github.com/Azure/azure-sdk-for-rust

These days I probably would not look at any language that did not have SDKs for AWS and Azure, for similar reasons.

What tools or libraries is Rust missing for building microservices?

They already mentioned AWS support was poor, which I can't confirm. I can say that GCP support is subpar. Comparing Python's GCP library with Rust's is a world of difference.

> It makes it easy for any random kid to dive into an existing code base and become productive, that can be super valuable

professional developers are rarely “kids”

Yeah, I think your view here is pretty close to the way I feel.

It's unfortunate, because I think Go generally gets a lot of stuff really right. But it too often feels that it prizes simplicity in implementation or specification over simplicity of how code is read and written.

Writing Go feels like having a little rock in my shoe. I think it comes from that situation where you know some property of the code you are writing (e.g. "this thing cannot be null"), but there is no method to assert this to the computer. And so instead of my very fast and logical computer with lots of memory enforcing this for me, I have to carry that knowledge around in my own lossy memory as a little bit of baggage and hope I never put it down and forget about it. And I find that this comes up in Go all the time.

That sucks because Go is still—despite all this—probably the best overall solution for the kind of apps I end up writing a lot. I really do think that there's still a space in there for a language sitting on the complexity scale between Go and others around the level of Java/Swift/Typescript, which can benefit from both some excellent design decisions of the former, and some of the expressiveness- and correctness-enhancing features of the latter.

> I like the idea of a simple language, but not the choices they made.

That’s the problem with simplicity, and it’s why kitchen-sink languages like Java will always be popular.

People complain about the complexity of Microsoft Office too — they only use a subset of the features. Why does it need to be so complicated? Because every customer uses a different subset of the features, and what you end up with is the combined superset of what everyone wants.

> That’s the problem with simplicity, and it’s why kitchen-sink languages like Java will always be popular.

Java is not kitchen sink. Scala is.

And Go is quite popular than Scala or Rust, which would count as more kitchen sink.

I believe what matters is immediate applicability for some purpose, which oftwn means some amount of 'kitchen sink'.

It’s a funny thing about simplicity. It’s easy to make something simple by foisting the complexity on the consumer. A lot of Go’s features are simple in that they take few words to explain, but using them uncovers so many edge cases that they wind up being quite complex.

You say "a lot". What's your third example?

The sad part of lack of sum types in Go is that the select operator is kind of a typical sum type operation to pick up one of sum type branches. So the language has this notion, but it is extremely limited.

Yep, and multiple return types are like tuples, minus the ability to compose them and actually use them as a single type. Map and lists were generic, but a special kind the user couldn't make (fixed now I think w/ generics in 1.18). 'range' worked over a magic iterator, but not one you could ever make. Their "enums" are variable bindings minus the ability to be sum types or any other decent property of an enum. Nil is nothing more than "None" or "Empty" in an Option type, but since they didn't use the type system you can get a classic null pointer exception. Their "attributes" are just comments, but now you need to remember their special formatting since each one is effectively arbitrary text.

In so many instances, they made things "special" to avoid bringing in a concept, but you have to learn that concept anyway, but now as a special case. It is almost as if they said "we can have 5 features and I don't care what #6 does..it is out...we must make a language with 5 features!". Instead of saying: "What is a reasonable set of features that compose well, are logical, expressive, and relatively simple such that people can both easily learn and scale their code bases".

A great example is Brainfuck. Everyone would agree it is 'simple' and it only has 8 constructs, but it is not 'easy' to write programs in. 'simple' is not the right metric for a language.

Go is a great case for why simple doesn't mean easy.

This is one of the warts I wish Go would fix (implementing Rust-like enums, and ideally getting rid of zero values and nils, but these things won’t happen). Even still, Go is the most productive language I’ve used because it turns out type-systems (cool though they are) are overrated—you only need enough of a type system to keep things documented for humans and tools. 95% type safety seems to be the sweet spot (peak productivity) after which productivity begins to rapidly diminish. It’s more important to have decent performance, good tooling (simple with sane defaults), small learning curve, great deployment story, etc.

I have never seen a language successfully eliminate nil/null and zero values after the fact. Once they're in, they're there to stay.

You can have robust and ergonomic code around nils if they are part of your type signatures and/or get some good language and standard library support:

In Clojure (Lisp) a nil is treated as a value which flows nicely through code, there are many idioms and utilities that are built for this and compose well. In Kotlin, Typescript, PHP there are unions which I find much more ergonomic than sum types for this use-case.

> You can have robust and ergonomic code around nils if they are part of your type signatures

Go has `nil` built into the type signature, but the problem is that all reference types are inherently nil-able, and value types can't be nil (although they can have their own in-band zero values). This means you either pass around values (with the entailed overhead and copy semantics) or you pass around nil-able references.

Why would unions be more ergonomic than sum types? Presumably they would have the same ergonomics?

> Why would unions be more ergonomic than sum types? Presumably they would have the same ergonomics?

For this use case (can be a some type OR nil) they are more ergonomic because it is an actual OR, not a separate container. You want the thing as-is and handle the case where it isn't there not go through an intermediary type.

I'm not sure I'm following. Rust allows:

    println!("{}", if x == None { "foo" } else { "bar" });

How would unions make this more ergonomic? For example, in Python (with type annotations), you would have to do:

    print("foo" if x == None else "bar")

Yeah, I have no illusions that Go will walk that back, especially considering its compatibility promise. It's a thorn in the side, but people also exaggerate it dramatically while overlooking major issues in other languages.

You sum up my 3-4 years writing in Go. I’m going to have to point people to this comment. Thanks.

regarding null: google's Dart recently got type-level null-safety.

Maybe that's planned for Go too?

I mean, they're both made in google, so...

> I think I would say overall that I like the idea of Go better than I like Go itself. I like the idea of a simple language

Agree.

I'm new to GO, and I keep bumping into language issues that upon further inspection where unilateral "opinionated choices" made by some secretive cabal. Don't get me wrong, I see plenty of public discussion, but ultimately some core GO team person abruptly closes the issues. Perhaps I'm exaggerating a bit, but there have been several times I've tracked an issue report to find the issue closed without sufficient discussion.

For example, The whole thing with exported vs unexplored things using the uppercase first character. This is both brilliant, and simultaneously prejudicial. The brilliant part is one need only to look at a variable's name to understand it's exported, rather than exhaustively searching for the declaration where something like "exported" reserved word was used... Instead the first character carries that information. But... many languages do not have the concept of upper/lower case...

Or the related issue of variables declarations or aliases having to be a Unicode "letter", and the designations of Unicode letters being narrowly defined in ways that prevent folks using their native language. To elaborate, that means there is no possibility to write GO in a world language like Chinese, Japaneses, Arabic, Hindi, Russian, etc.. The language must have the properties of 1) being letters, not having any non-letter modifiers, and having upper case letters.

The problem is many languages have funky characters that are technically symbols (not letters) in Unicode, but are used in combination with Unicode letters to modify the meaning of a word. Similar to accents, or whatever hats go above some Latin characters, other languages have a whole other symbol left or right of the character to do similar things. But variables may only contain "letters".

So to rephrase this issue, GO is an English programming language, which ironic because one of it's creators was purportedly one of the people involved with creating UTF-8 as a replacement for ASCII, and yet GO is saddled with issues similar to how ASCII limited C way back in the days. So it's like these neck-beards propagated their biases and prejudices into the GO language.

Another criticism I've got pertains to GO's understanding of numbers. I'm so tired of numbers being an emergent property of the underlying hardware architecture. You know, when we went from 16bit to 32bit, and again from 32bit to 64bit... GO has perpetuated the silly idea of tying number types to the underlying architecture hardware architecture, and that has silly effects on writing portable software. In the year 2008 (GO's approximate inception) or the year 2022 it's entirely feasible to have numbers mean one thing always, and the runtime does the needful to ensure that number just works with respect to the underlying hardware. In your lifetime, there is a very real chance we may see the emergence of 128bit architectures, if anything for the expanded arithmetic,or expanded register size, less so for the absurdly huge memory address space. But now we are locked in to how GO was conceived at it's inception....

I would really like to use a language like the idea of GO, but not GO itself. It's seem s evident GO will not break the compatibility promise/contract to improve the lang or reverse bad choices, and the utterly brilliant people designing & implementing GO apparently hold bad opinions. I've seen this before in so-called meritocracies, you tend to see brilliant ass-holes fizzle to the top. Don't get wrong, nobody on the CO core team is an ass-hole, I'm obviously exaggerating to convey my point... it's a variation of reduction-absurdum fallacy.