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".
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.
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.
An "Any type" is optional typing if you don't need to downcast it in order to use it, like the "any" type in TypeScript and Flow.
If the "Any" type is just a top type but you have to downcast it to use it, like in Kotlin, then it's not considered optional typing, since you still have to talk about types ;).
You're right. Java is a decent language with a decent type system (bar the lack of null safety and some other quirks). It's all the annotations and reflection and XML and magic that creates most of the pain, and that's the fault of the library and framework developers, not Java itself.