> The weird "return tuple" , which obviously just exists for errors because there is not a single other place where you can use tuples in the language

MRV, go does not have tuples.

Go is not the only language with MRV (as a special case) and they’re not necessarily bad, iirc Common Lisp uses them as auxiliary data channels and has a whole host of functions to manipulate and refit them.

Go is singularly incompetent at MRVs though, in the sense that only syntax and builtin functions get access to variable arity (e.g. if you access a map entry you can either get one return which is a value, or two which are the value and whether the key is/was in the map). So MRVs mostly end up being worse tuples infecting everything (e.g. iterators needing Iter and Iter2 because you can’t just yield tuples to for loops).

I forgot:

The tenet "accept interfaces, return structs" is violated all over by returning the `error` interface.

IMO it's okay to make behaviour-exceptions specifically for error handling. Rust for example doesn't really have builtin behaviour exceptions specifically for errors, they're generic to sumtypes and just happen to work well for errors. But then in practice you must resort to thiserror or anyhow helper crates to deal with errors in anything but tiny programs.

If you do make behaviour exceptions for error handling, be honest and upfront about it. Don't say "errors are just values so just use them like regular vars" in docs, if then there are several huge exceptions (tuple-returns and breaking a core tenet). If you make exceptions then you might as well do them right, instead of half-assing them. I believe zig does it right, but I haven't gotten around to try it.

Rust and Go's lack of stack traces are basically equivalent in that you need to call an additional function to add the stack context to the error result. For go you use fmt.Errorf, in Rust you use .context from anyhow (bad practice in many contexts IMO) or .inspect_err + log. It's rather unfortunate that neither has an easy way of capturing a line number + file easily and appending it to the context. Go could easily do it, I think. Oh well.

I agree that Go should really have an analogue to Rust's `?`, but you can't really do that in a sane way without sum types to represent your conditions. The very multiple-return style error propagation makes it impractical to do.

IMO Go should add really basic tagged unions and rework the stdlib to use them, but such a change would probably necessitate a v2.

Alef actually has/had real tuples, as does Limbo.

Looking at Alef, apart from using tuples to provide multiple return values in a C-like language, they don't seem to actually add much functionality over what Go has without them. One of the few extra things is the ability to pass a tuple over a channel, however passing a struct is more or less equivalent.

I've not looked in much detail at what Limbo could do with its tuples.

So maybe they don't really add that much, hence why they were not carried over when Go was created?

Alef had enums, Limbo has something like the Go constant scheme and iota. Limbo also had tagged unions / varient-records, in a sort of Pascal like fashion - the "pick adt".

> The weird "return tuple" , which obviously just exists for errors because there is not a single other place where you can use tuples in the language

Go functions also accept a tuple on input. While theoretically you could pass an error, or a pointer to an error for assignment, it is a stretch to claim it is for errors.

https://github.com/pkg/errors provides stack traces support. This unfortunately did not get included in the Go1.13 release when error wrapping was introduced.

I prefer the structure of Rust errors as it’s fully typed, I don’t like that you can chain them though. It’s a cool feature but it leaves you with some of the same issues exception handling does when the freedom is used “wrong”.

Exceptions are sum types, they just have different syntactic sugar.

Well, I've also programmed for over thirty years and I wouldn't use a language without exceptions and even wrote a whole essay defending that position:

https://blog.plan99.net/what-s-wrong-with-exceptions-nothing...

> Even junior engineers have a trivial time debugging most go errors

Not my experience at all. I had to do this once. An HTTP request to a production server was yielding a 400 Bad Request with no useful information for what was bad about it. No problem, I'll check the logs and look at the source code. Useless: the server was written in Go and the logs had no information about where the error was originating. It was just getting propagated up via return codes and not logged properly. It ended up being faster to blackbox reverse engineer the server. In a language with exceptions there'd have been a stack trace that pinpointed exactly where the error originated, the story of how it was handled, and the story of how the program got there.

Diagnosing errors given stack traces is very easy. I've regularly diagnosed subtle bugs given just logs+stack trace and nothing else. I've also had to do the same for platforms that only have error codes that aren't Go (like Windows). It's much, much harder.

> never handled correctly

I’ve seen this argument, but if you look at real golang code and examples, it’s just a bunch of “if err <> nill” copy pasta on every line. It’s true that handling errors is painstaking, but nothing about golang makes that problem easier. It ends up being a manual, poor-man’s stack-trace with no real advantage over an automatically generated one like in Python.

Many people against Go's error handling do not advocate for exceptions, but for a combination of an Either/Result type (for recoverable errors) and fully aborting (for unrecoverable errors).

But with Exceptions you can easily implement multiple return types in e.g. Java ;)

I shocked my Professor at university with that statement. After I started laughing, he asked me more questions... still went away with a straight A ;D

Exception and explicit on-the-spot handling are not the only two ways to handle failing processes. Optional/result types wrapping the are a clean way to let devs handle errors, for instance, and chaining operations on them without handling errors at every step is pretty ergonomic.

Is “goto” just used to mean “bad and evil” here? Because exceptions are not a goto anymore than a return is a goto. The problem with goto is it can jump to any arbitrary place in your code. Exceptions will only go to catch-blocks up the call stack, which presumably you have written on purpose.

I agree about implicit exceptions, but I think that there is a sweet spot with explicit exceptions like Swift (and maybe Java): where you cannot not-handle one, it is part of a function's signature, and the syntax is still compact enough that it does not hurt readability.

Hard disagree. Exceptions are actually good. They make code clear and errors hard to ignore. I've written a ton of code over decades in both exceptional and explicit-error languages and I'll take the former every day. There's no function color problem. No syntactic pollution of logic with repetitive error propagation tokens.

Also, exception systems usually come with built in stack trace support, "this error caused by this other error" support, debugger integration ("break the first time something goes wrong"), and tons of other useful features.

(Common Lisp conditions are even better, but you can't have everything.)

You can't just wave the word "goto" around as if it were self-evident that nonlocal flow control is bad. It isn't.

> And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about.

That's not been my experience at all. Writing exception safe code is a matter of using your language's TWR/disposable/RAII/etc. facility. A programmer who can't get this right is going to bungle explicit error handling too.

Oh, and sum types? Have you read any real world Rust code? Junior developers just add unwrap() until things compile. The result is not only syntactic clutter, but also a program that just panics, which is throwing an exception, the first time something goes wrong.

Many junior developers struggle with error handling in general. They'll ignore error codes. They'll unwrap sum types. They might... well, they'll propagate exceptions non-fat ally, because that's the syntactic default, and that's usually the right thing. We have to design languages with misuse in mind.

Here, you've found me.

I don't LIKE it, but it's acceptable.

I have been working with Rust since 2015 (albeit not professionally, but a lot of side projects) and love it.

But I also dabbled into go the last couple of months and while it has its warts, I see it as another tool in the tool-belt with different trade-offs.

Error handling is weird, but it's working, so shrug

I dislike sum-type based error handling. It is annoying syntactically and only really doable with lots of high-level combinators, which in turn hinder debuggability.

I think it’s because Go is an alternative to Java and C# more so than an alternative to Rust. It is for me at least. As I said, Rust isn’t seeing any form of real world adoption in my region while Go is. Go isn’t replacing C/C++ or even Python though, it’s replacing Typescript, C# and Java. Now, there are a lot of good reasons as to why Go shouldn’t be doing that, a lot of them listed in the article, but that’s still what is happening.

As I pointed out I think Rust does it better with its types error handling. That isn’t too relevant for me though as Rust will probably never seem any form of adoption in my part of the world. I think Zig may have a better chance considering how interoperable it is with C, but around here the C++ folks are simply sticking with C++.

You hit the main gripe I have with Go, its types system is so basic. I get people raving type-correctness of Go when they come from Python but the type system in Go is simply pre-historic by modern day standards.

That’s to be expected since it is marketed towards beginner and casual programmers.

FWIW... WebAssembly has Option and Result, and adapters for Go.

> yes it's noise because whenever read a codebase for the first time you are never interested on the the error edge case.

maybe this has something to do with how bug-prone it usually is for a new hire to modify a codebase for the first time in most orgs

you could also just do things fail-fast style and panic everywhere if you REALLY wanted to stop inlining error conditions. or ignore error checks until some sort of guard layer that validates things.

IME you usually don't want to do either of those things, and the go approach at least encourages you to think about it closer to the site than checked exceptions (which you can more easily toss up and up and up and auto-add to signatures of callers). unchecked exceptions are arguably less-bad than "just ignore go return errors" - they'll get seen! - but terrible for a reliability/UX perspective.

optional-esque approaches are nice but just a different flavor of the same overhead IMO.

Do you have examples for the latter?

> It forces you to think about all of the possibilities your code might generate.

Except it doesn't actually. You can totally just ignore it and pretend errors don't exist. Lack of sum types/Result, and pointers as poor mans optional, really hinder's Go's error handling story.

> It forces you to think about all of the possibilities your code might generate

I’ve seen way too much Go code which never even tested the err value to believe that until something like errcheck is built in to the compiler.

I do agree that this is a plus for the explicit model but that’s been a better argument for Rust in my experience since there’s better culture and tooling around actually checking errors. I’m sure there are plenty of teams doing a good job here, but it always felt like the one lesson from C they didn’t learn well enough, probably because a language created by experts working at a place with a strong culture of review doesn’t really account for the other 99% of developers.

Rust handles this much better.

Error handling is still explicit, but it gives you the tools needed to make it less tedious.

As a regular Go user, I agree with this take. Though the tools exist, error wrapping and checking (with errors.Is and so on) is actually pretty rare in my experience.

Positive example of good and appropriate usage here: https://github.com/coder/websocket/blob/master/internal/exam...

This is down to developer style and agreements though; Go has typed errors and a set of utilities to match them [0]. Not using those is a choice, just like how in Java you can just `catch (Exception e)` after calling a dozen methods that might each throw a different exception.

[0] https://pkg.go.dev/errors

Exceptions are difficult to discuss because different languages implement exceptions differently, each with their own downsides. That said, I don't think anyone has an issue with bubbling. Even sum type proponents love Rust's ? shorthand, because it makes it easier to propagate Results up the stack.

The big issue with exceptions in C#, Python and JS is that they're not included in function signatures, which means you have to look up the list of possible exceptions from documentation or source code. This could be amended with checked exceptions like Java, but it allegedly doesn't mesh well with the type system (I haven't personally written Java to confirm this). And then there's the C++ crowd that slaps noexcept on everything for possible performance gains.

Personally, I like the way Koka does exceptions with algebraic effects and type inference. It makes exceptions explicit in function signatures but I don't have to rewrite all the return types (like in Rust) because type inference takes care of all that. It also meshes beautifully with the type system, and the same effect system also generalizes to async, generators, forking and other stuff. Alas, Koka is but a research language, so I still write C# for a living.

> They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about.

I think that’s misdirected but illustrates the emotional reasons why people develop a negative impression of the concept. Usually it means someone had bad experiences with code written in a poor culture of error handling (e.g. certain Java frameworks) and generalized it to “exceptions are bad” rather than recognizing that error handling isn’t trivial and many programmers don’t take it seriously enough, regardless of the paradigm. As a simple example, C and PHP code have had many, many security and correctness issues caused by _not_ having errors interrupt program execution where the users would have been much better off had the program simply halted on the first unhandled error.

If you write complex programs with lots of mutable shared state, yes, it’s hard to reason about error recovery but that’s misattributing the problem to the mechanism which surfaced the error rather than the fact that their program’s architecture makes it hard to rollback or recover.

C# can compile standalone binaries for multiple platforms.

Basic Rust doesn’t take months to learn, especially when you’re not trying to do things like distributing crates to other people. I found the compiler to be enough more helpful than Go’s to make them roughly time-equivalent for the subset of common features, especially for a simple CLI tool.

More importantly, Rust has the notion of a result type and it is designed to be both generic and composable.

A problem I often face in Go and TypeScript code is code that ignores errors, often unintentionally. For instance, many uses of JSON.parse in TypeScript do not check for the SyntaxError that may be thrown. In Go, it is common to see patterns like

  _ := foo.Bar()
  // assume Bar() returns error

Also, the position of the error matters. While the convention in the stdlib is to return errors as the final value, this isn't necessarily followed by third party code.

Similarly, errors are just an interface and there is no requirement to actually handle returned errors. Even if one wants to handle errors, it's quite awkward having to use errors.As or errors.Is to look into a (possibly wrapped) chain of errors.

The benefit of Rust's Result<T, E> is that

- position doesn't matter

- there is strong, static type checking

- the language provides operators like ? to effortlessly pass errors up the call stack, and

- the language provides pattern matching, so it's easy to exhaustively handle errors in a Result

The last two points are extremely important. It's what prevents boilerplate like

  if err != nil {
    return nil, err
  }

> Rust eventually realised this and introduced try! and ? to simplify this

That was prototyped around Rust 0.4, so I wouldn't say "eventually" :)

Unsure if this is the right place to ask, but this conversation inspires me this question:

Is there in practice a significant difference between try/catch and Go's "if err" ? Both seem to achieve the same purpose, though try/catch can cover a whole bunch of logic rather than a single function. Is that the only difference ?

I felt the same but after switching to anyhow and thiserror in pretty much every Rust project I work on I find it quite painless. It's not ideal to rely on crates for a core language feature but I never find myself fighting error types anymore. Have you tried those crates? Do you still hold that opinion?

The problems you're describing don't exist in go. There is exactly one standard type that is used by everyone, at least in public API's, you can always just return the error to the caller, if you don't want to handle it in place. The main difference with exceptions in my practice is the fact that it's a lot easier to mess up, since it requires manual typing. This is probably my main problem with everything being as explicit as possible: it requires people to not make mistakes while performing boring manual tasks. What could possibly go wrong?

Different kind of magic. Needing to account for every single line of code being able to throw an exception is very mentally taxing, whereas the existence of a GC removes mental load of needing to account for every single allocation.

How does RAII works in concurrent systems ? It seems to me you need to add compile-time object lifetime evaluation (as in rust) which so far incurs a high toll on language complexity.

Don't forget that it's made by someone trying to sell you an IDE!

I think this is a really wise take, and one that I honestly haven't seen before. I would certainly try a language like this.

The one thing I would add: Provide a well-trodden path to easily drop down into Rust/C/C++ for performance critical functionality. I have found this to be a big point in Python's favor over Go; you can write things the slow way (ie. executing in the Python runtime), then profile and figure out where to push things down into an extension. Often you're doing something that already exists in a library like numpy or pandas or polars, but if needed, you can write your own extension.

Does WASM enable FFI on its own?

I think here you're pointing at something along the lines of Roc/Gleam?

IMHO it's just that it's a beam VM language, which is a fatter runtime/ecosystem than is really needed to achieve the goal stated above can bring it's own bag of problems (but also it's own superpowers).

Also to be productive you have to utilize the rest of the erlang ecosystem, so at least some superficial knowledge in elixir & erlang is helpful for for some use-cases.

Syntactically I actually don't think it's that for off, but I dunno what GP was thinking, maybe that it leans more into functional patterns & sugar for those whereas rust/go can also be used in a procedural style. (Though at least personally I am using way more functional patterns in rust than I expected)

I love Crystal, but the lack of a proper LSP and tooling makes it hard to just jump in and adopt for bigger projects.

Unfortunately, Nim's BDFL is... not known for playing well with others. Perhaps the Nimskull fork will grow into something widely useful?

https://github.com/nim-works/nimskull

If they'd drastically improved their tooling then yes.

But sadly it's not that easy to create a statically liked binary in swift. The last time i did it it also included the whole runtime, and the resulting "hello world" binary was 50mb large. Annoying at least.

For years I wished they got their stuff together, but at this point I'd be very suprised. They probably have too much technical dept already due to the support of XXX edge cases Apple need for iOS/MacOS development.

> relatively simple

Last time i tried to install ocaml on windows few months ago i failed to do so, it's a well known thing that it is not 100% supported on windows therefore it wont have the adoption that go/rust has (as it's been the case forever now)

This doesn't count because the idioms are very different from Go and Rust. And I suspect there's a high learning curve for features like Functors.

If you check the Wikipedia page for OCaml to find out where it gets used, you'll see why it's ocaML. That is, you'll notice that it's mostly a MetaLanguage, or a language for writing other languages. The same observation applies to other languages in the ML family.

Stretching 'currently available' a little, there's Roc lang [1]. Though still in development, you can use it for small personal projects. Another caveat is that it's a functional language, which could potentially hinder its wide adoption

[1] https://www.roc-lang.org/

I have no idea why anyone would say it's not simple, it's super-simple. Learning how duck typing works with interfaces and how to use it is perhaps the only hurdle. In my experience, only certain BASIC dialects like VisualBasic are simpler.

This 100%, I was just about to type a long rant up about this. There are so many weird parts of the language that took me forever to grasp, and in many cases, I still don't have an intuitive grasp of things.

And plenty of other examples that aren't in that article:

- You have a struct with an embedded interface. Does the outer struct satisfy the embedded interface? And can I type assert the outer struct into whatever embedded struct is fulfilling the inner interface?

- When should I pass by value and when should I pass by reference? Like I generally know when to choose which, but do I really know without performing a benchmark? And what about arrays? Should I store pointers in them? But it also seems that people just don't care and just randomly roll the dice on when to return a pointer or a value?

- Shorthand variable declaration. How does it work when you shorthand declare two variables but one of them already exists?

Don't both answering the questions, that's not the problem. The problem is that it's just not intuitive enough such that I'm confident I know the correct answer.

It's easy not simple, but the consequence is that any complexity that other languages handles for you, in go gets forced onto the developer.

There's more stuff to think about, because the language is doing less for you.

Yes, like "Opening Brace Can't Be Placed on a Separate Line" (from your link).

Everyone can read Go code and understand what happens. There are some minor difficulties like func (*A) vs func (A).,

"quickly find yourself wanting slightly more modern language features."

Use the tool that works for you.

That quote sounds like an argument against Rust, not GO. Rust is a complex language and that complexity doesn't go away if you close your eyes to it either. All complexity adds to project complexity.

Speaking a someone who has written Go full time since 2014:

Go is used in a lot of places for unglamorous things where the most important thing is explicitness, and where all these features that the PL nerds want, do nothing but make things more implicit.

It's not perfect, but it's a great language. People who like it, though, like me, are pragmatists. The shortcomings of the language that are apparent in complex code are strengths when writing the simple straightforward code that makes up most Go projects, because all of THAT becomes much simpler than it would be in a fancier language.

The reason I've never bothered to write a response to these kinds of screeds against Go is that usually I'm too busy getting shit done with it.

Dear christ yes.

“Go is designed as a systems programming language” has been retconned so that “systems” is redefined to mean programs talking over a network?

“Real programs won’t use repetitive error handling, but build on top of it.” I don’t think this one needs further explanation.

“Go doesn’t need xyz.” This is just the slow and painful process of the golang community realizing one at a time why other languages have the features they do.

“Explicit is good.” Explicit and verbose are not the same thing. You can have explicit and terse.

“Golang is simple.” Golang is primitive, not simple. There are tons of footguns and gotchas, not all of which are chronicled in the linked essay, which would have been so easy to avoid. And everyone just collectively internalizes these issues as if “just avoid writing those bugs” is a sane mindset any different than the languages that came before.

“Go doesn’t need a package managers.” Oops, it did. Now we’re like three attempts deep.

Over and over and over I feel like we’ve been gaslit and told we’re crazy, only to later on have the community act like (for example) golang always intended to add generics and of course they’re a good idea.

Yes, I've also grown tired of this toxic mindset, as well as the whole "idiomatic Go" dogma that is very often an excuse for poor engineering practices.

Yeah, this was/is a part big part of my frustration with the ecosystem too. It set a LOT of very problematic patterns in place in the beginning, and many of them are still not unwound.

Stuff like "Go doesn't need dependency injection because it's simple". I heard that literally dozens of times. The opposite is true! It's an even bigger pain without DI because the language is so simple! DI everything or make your users suffer!

Or a personal favorite: "Go doesn't need a package manager". We see where that went, and how much insanely better it is now that we have it.

Or errors. Without wrapping. Oh boy we're gonna pay for that for decades.

There's stuff to like in the language, but the zealots (especially early ones) really did not know which parts they were.

There's no tool boring enough to prevent any chance of regret. At the end of the day, it's really, really difficult to anticipate where your pain points will actually wind up in the real world. In practice, I've had lots of really good production success with Go and not too much heartache about the choice. Since adopting it personally (in around 2014) almost every company I've gone to work since has used Go in some capacity and that capacity was usually growing because it was working for them.

Will you regret choosing Go? Maybe. Or, maybe not.

Go is as boring of a tool as it gets. Which is why I will happily use it

No, because it's an example of someone who chose Go and didn't regret it, and continues to choose Go, because the objections of the article are in practice just not very important or compelling.

There's plenty of software I work on from time to time that's written in Go which I'm happy are written in Go. Some of those were even projects which I started and chose the language for.

Then there's software I've been involved in where I believe Go was the wrong choice. And software not written in Go where I believe Go would have been the wrong choice.

My point is, Go is just another programming language, with a unique set of strengths and weaknesses, and there are plenty of cases which i have experienced myself where there are genuinely no regrets around picking Go. Not because there aren't shortcomings in Go, but because there are plenty of cases where those shortcomings don't matter.

In my professional life, I have seen significantly more regret associated with choosing JavaScript on the back-end than with choosing Go. But then again, there are services in production written in JavaScript where that just never has been an issue and there are no regrets.

In my personal experience your average go developer that likes go, likes it because he doesn't really know anything else.

As a result most things written in go are, in my own experience, of lower quality compared to things written in other languages.

So using things written in go is usually my last resort, because I expect they won't be high quality before even downloading them.

Uhh, maybe.

Where is the tradeoff analysis? Yeah, you might regret using Go when some zero value you forget to fill in somewhere pops up later and ruins your pipeline. But are you considering all the issues that didn't pop up because you chose Go?

Java's boilerplate code? Rust and C++'s lifetime analysis and memory management? C's lack of tooling? Python/Typescript's runtime errors? Functional languages' tiny employee pool? How much did trouble did you save by avoiding these?

>I don't understand why people get so passionate about programming languages. They are tools.

Because when you're a professional programmer, tools are a huge part of what you do and how you do it, same like a race driver would need to be passionate about cars.

It's just that for an e.g. carpenter, tools are more or less standadized and simple enough to evaluate.

If saws and hammers and routers had as much variety as programming language tooling, and were as multi-faceted to evalute, carpenters would be absolutely obsessed with using the good ones - even more so than they already are.

"Manager imposes it on you" just means you work in a team rather than alone. You can pick whatever you like for side projects, of course you're going to use whatever your team uses otherwise.

More generally, when it's not well suited for the problem to be solved. Eager coworkers anticipating Google level traffic may want to write the system in Go and multiple microservices when a simple FastAPI server would do.

Plenty of software engineers don't know any better themselves

Only a problem when a manager imposes it on you for a program where it doesn't fit well.

Counterpoint, other languages - notably Javascript, Scala, PHP, maybe Java - have taken the stance that they adopt other languages' features, not because the language needs it, but because developers were clamoring for it. Which led to added complexity, because they kept adding more and more ways to solve a problem or structure an application, which led to every codebase being so different from the next that the amount of transferable skills and knowledge became less and less. Scala is the worst offender for that IMO.

One frequent praise one hears of Go is that a developer can open any codebase and immediately understand what's happening. Go is readable and stable, which are critical for code for the long term.

I love the fact that I can pick up a Go project from 5+ years ago and it still compiles with the current toolchain. I might need to do a 'go mod init' first.

It didn't get 67 new features that start shooting deprecation warnings on old functions in the meantime. I don't have to learn new paradigms or switch integral parts of my code to something new.

Generics has been in Go for dunno how long, haven't used it once. Didn't need to.

And a lot of people using Go have experienced other language features as well and either decided against them or that the whole tradeoff was not worth it.

I will keep very fast compilation times and decade long backward compatibility over a lot of your features. Because those are features too.

And since Go is so readable, theoretically getting the core functionality out and rewriting it in a more specialized language would be fairly straightforward. And while it's an investment in time and effort to rewrite a chunk, at least you know what you're writing already.

But that's a point made in the article, that Go is also good for prototyping. But there's a few languages good for that, e.g. Ruby which powered a lot of the HN startups in their early days until parts needed to be rewritten for performance / scalability.

But writing a new, unproven product in a high performance, high difficulty language from the get-go is cargo cult; you hope you will need the performance and correctness offered by the language. Meanwhile, halfbaked hack jobs like Facebook and Twitter exploded in popularity and revenue, and while their performance issues gave their developers headaches, at least they knew what problems they had and had to solve instead of guessing and hoping.

> consistency of code

There are many stylecheck tools that should be apart of a good stack. Accepting the creator's style is putting a lot of weight on their opinion. Most organizations have their own preferences for good reason.

> short ramp up for junior engineers

Junior engineers aren't a place you're concerned on being productive. Most of the time at that stage in someone's career they should be learning more, getting up to speed with professional practices, tools, and trying to learn code bases+patterns. Ramp up time for a language is a very minor consideration.

Both of those things have very little to do with server environments.

Bigger corporations struggle with Go's module system and forced reliance on seperate repos for separate modules. (Can you bundle multiple modules in the same repo.. yes but you're going to have a bad time)

How is Go an iteration of C? You can't use Go to write a kernel, or program a microcontroller, or for high-frequency trading or a web browser or a tensor library or a language run-time. It's either a bad idea or simply impossible, depending.

Someone please explain to me what's C-like about Go other than vaguely the syntax and that it compiles to machine code.

They should consider Java though.

People have an irrational hate for it based on the enterprise cruft and horrible third party frameworks you can just completely ignore if you build a new thing

It's not good for commandline stuff but for a long running small service it is pretty great