Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
>> Made by really famous veteran language designers
Yeah that’s a positive
>> Backed by Google
But that’s a negative, https://killedbygoogle.com/
I definitely think you’re too fast to dismiss the language features contributing to popularity. As an example:
Fast builds are a positive developers immediately warm to when they experience them (stand by for rustacean “i need time to make tea and my compile times are exactly the right length for tea break” type comment). The example of the 4.4mb c++ project that results in the compiler ingesting 8Gb of data is eye opening. C++ needs to resolve type information for all includes and all their includes and all their includes… go only needs the interface so compilation can be done without all that effort.
We can sort of evaluate of much "backed by Google" means by looking at other languages backed by Google. The main one I have in mind is Dart. Here's a few links:
- https://madnight.github.io/githut/#/pull_requests/2021/4
- https://www.tiobe.com/tiobe-index/
- https://redmonk.com/sogrady/2022/03/28/language-rankings-1-2...
Dart seems to be doing relatively well. Considering Go has more things in its favor than Dart, it's logical that it's doing better. Still, the Google boost seems to be really big.
esbuild [0], a JavaScript bundler written in Go, made waves in the frontend community by being 10* faster than alternatives and written in Go (as opposed to Node.js which is the usual choice for obvious reasons).
There are curated lists of Rust crates to help with the second issue: https://github.com/rust-unofficial/awesome-rust
And those two options don't strike me as equally unattractive. Writing everything that isn't in the standard library from scratch is completely impractical for modern apps. Nobody does that in Rust. Integrating crates from the ecosystem into your workflow is just part of developing in the language.
> Android is C/C++
It really isn't, and frankly this sort of comment makes it quite clear how uninformed you need to be to make this sort of claim. I mean, even the Android NDK specifies quite clearly in its own description that it's only designed to offload parts of an Android app to C++.
https://developer.android.com/ndk
In the Android projects I worked, the Android NDK was only used to implement small performant components that sat on the hot path, such as image processing work. Even so, the experience was not exactly on the happy path.
> I stand my point, the JVM is not the right tool to build components for Kubernetes because Kubernetes needs lots of small service running everywhere, running those in the JVM would have resulted in large memory consumption.
This personal assertion has no bearing in the real world. Not only do we have high frequency trading apps developed in Java but you're also succumbing to absurd beliefs that you get architectural wins for free by switching the programming language.