Its absolutely laughable that Gophers act like their language solves concurrency when its actually worse than Java because it has data races. Go added nothing and moved backwards.
The language that actually solves concurrency is Rust, but they will never acknowledge that.
The single executable deployment hasn't been an advantage for a very long time. C# has Native AOT. Java/Kotlin/Scala have GraalVM native-image, plus Kotlin Native and Scala Native.
And of course there is Rust, which compared to Go has better performance, lower memory usage, smaller binaries, safe concurrency, safe resource handling, and a real type system with tagged unions.
The Go team built good tooling around a mediocre language. Now most other languages have caught up, and Gophers are left writing mind numbing `if err != nil` checks with no benefits left to show for it.
Go has plenty of hidden code paths in defer, panic and recover. You can minimise the use of those things, just like in other languages you can minimise use of try-catch in favour of a Result sum type, which is already better than Go's "multiple return that you have to pretend is a sum".
Which is what should be discussed about go, rather than if-err clauses. That is hardly an issue in go. But Go has these little quirks which, if not careful, can become a problem. But instead most go critiques discuss only the error handling syntax. Look at the other comments.
The article is on point on the strengths of go, and in many cases, those other languages you say, you will find it really hard to do the same thing with the ease with which you can do in go.
What the article glosses over, is the footguns with working with the language. No compile time nil checks, implicit interfaces, lack of sum types, like you said, which more so often leads to bloated structs, member visibility which is just private and public. You can find more.
But these problems were not the main focus of go. Go was build because google devs wanted a simpler way to manage and deploy their software across thousands of services, not having to wait forever for their code to compile, not worrying about writing cpp code in the BEST possible industry standard, ability to do parallel processing of hundreds or thousands of workloads without choking your cpu, managing dependency hell. These were actual roadblocks. And google was not the only one facing these problems. Go solved all of it. Which language was solving this before go?
Go was developed because two UNIX guys, and one Oberon guy, that didn't like C++ decided to create their own thing, and their manager decided to support them as their 20% project.
Nothing else.
The narrative of Google wanting Go never happened, it gets sold as such by many Googlers.
Even Kubernetes was originally written in Java, before some Go folks joined in and drove the rewrite into Go, which besides the Android build system are the only two key projects using Go.
Most of that was written by the Go team, not Google management, and even has the famous Rob Pike take on it.
The You Tube download rewrite from Python to Go, wasn't a management decision, rather yet another case of Go team taking language marketing into their own hands.
You will find posts from me on golang-nuts pre-1.0 days, as I was hopeful it would turn out differently back then, so I don't need education on how Go came to be.
> Most of that was written by the Go team, not Google management, and even has the famous Rob Pike take on it.
I am unable to understand your point or you seem to be making arguments that have nothing to do with the article nor with my earlier replies. I wonder why. Are you expecting sundar pichai to announce golang to his shareholders in his quarterly call? Which language does that?
This article and my replies are technical in nature. You need to have a technical response to a technical problem. You cant get emotional everytime. Which language allows me fast builds, lightweight and high performance concurrency, strong stdlib and tooling, easy cross compilation with static binaries, simple syntax, decent performance and by that i mean not worrying too much on memory management, easy onboarding and large scale maintainability? I am willing to try that tool.
Because your narrative is wrong, it wasn't a Google project, it was a group of Google employees that rebeled and were lucky to have their line manager support, given being UNIX idols.
Google upper management was, and is, perfectly fine with Java, Kotlin, C++ and Rust, for the most purposes.
I won't suggest any "technical" answer, because clearly you only want Go.
Yes, languages with very strong type systems like Rust are incredible when paired with an LLM. Just like chat bots have a calculator as a "tool" because they are not the best at calculation themselves, they need a type system to deterministically validate the safety and cohesion of the code they generate.
Its languages like C that you have to watch out for, because the LLM will gladly say "this is safe!" when its not.
I migrated a monorepo including C++, Kotlin, Java, TypeScript and Python to Bazel. It's no small feat, and the DX varies widely across languages and platforms, but it's absolutely worth it. `bazel test //...` from a fresh clone builds & tests everything including gRPC/protobuf code generation, custom code generation, downloading packages, toolchains and linters, dependencies between langs, test suites with coverage across multiple languages.
Integration testing is a breeze through data dependencies. The reproducibility guarantees means we can reference container image SHAs in our Terraform and if the image didn't change the deploy is a no-op.
Bazel is an outstanding build system that handily solves a lot of practical problems in software engineering. Not just "at scale". Practical problems at any scale.
This is the ideal situation. Google already lacks control over all the Chromium forks, like Brave, Opera, Edge and ungoogled-chromium. They accept upstream patches voluntarily, and they can and do reject anything they disagree with. The shadier Google gets the more forks will reject upstream and instead share patches among themselves.
As long as Chromium is open source I don't see what there is to worry about. We literally have the code.
There's a lot to be gained by standardizing on Chromium as well. New features, improvements and optimizations only have to be implemented once instead of thrice, and developers only have to deal with bugs in one implementation instead of the union of bugs in all three.
This is fine; but still it hurts me to think that an open protocol of HTTP[S] and friends is effectively accessed by a single client at core. Yeah it's wrapped with different toppings by different vendors, but deep inside it's one client.
We're going from a world where we had IE, Google, Firefox and Safari as independent projects, we're going towards one with just one.
How is Windows any better? Last I checked installing things in Windows was still a matter of downloading random .exes from the Internet and running them as administrator, so all bets are off.
And there's no sandboxing at runtime either, everything has permission to do whatever the user can do.
I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer.
Once programs are running on the machine with the ability to put things on-screen and read keyboard input, this is a very hard problem without hardware-level SAK-like mechanisms which AFAIK no consumer devices include today.
The updated mnt reform [0] has some potential for this kind of facility with a keyboard-embedded display connected to a standalone EC and a dedicated button on the keyboard for notifying the EC without the host's involvement. This should enable an actual SAK-like mechanism, where the EC takes over the keyboard for security-sensitive actions like password entry:
> The keyboard not only works as a USB HID device, but it also has a direct UART
> cable connection to the system controller on the motherboard. By pressing the
> circle key, you can interact directly with the system controller, bypassing
> the main SoC. To give you visual feedback for this interaction, we added a
> tiny 128 x 32 pixel OLED on top of the keyboard. From here, you can check
> charger and battery cell status/health without any operating system support on
> the main SoC (even while you’re still installing an OS). The keyboard OLED and
> direct interaction mechanism has more potential future uses, like a password
> manager/wallet or notification display.
It's a non-trivial problem even with hardware assistance, without any it seems impossible.
> I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer.
Qubes OS can. Though it's not for the average users.
It's more that it makes said sudo much less effective. You still can get tricked inside the VM or a canny enough attacker will find a bypass for VM security.
It is a somewhat higher bar though.
The point is moot, as the most destructive attacks are ransomware, which this limits but does not prevent, website ID (login, address, credit card) and data theft, phishing and scams.
None of which is prevented by Qubes.
Evil maid attacks are frustrated though if you install its extra security features.
However, it is wise to remember that security is as strong as the weakest link, so do use it if you're an admin or dev.
> The point is moot, as the most destructive attacks are ransomware, which this limits but does not prevent
Qubes OS assumes (promotes and helps with) that you do not open random links inside your banking or important VM. You can even open links automatically in a disposable VM upon a mouse click. It should help here I guess.
> bypass for VM security
VT-d virtualization was broken only once by a software attack. An it was done by the Qubes founder.
Unfortunately in reality Windows doesn’t do much better. For instance the author likes to harp on about the insecurity of X11 while on Windows GUI programs have rather similar levels of access to each other, including to APIs that have impossible to fix buffer overflows that stem from their 80s style design.
Yes there is a (semi) Secure Attention Key but it isn’t required in many cases such as while requesting consent for elevation and you can set it to required but it comes with a warning that that breaks important things (and it does).
The language that actually solves concurrency is Rust, but they will never acknowledge that.