People are not talking that InfluxData is NO more just a time series database, this isn’t just a language change but feature additions and with the level of massive dependence on C++ libraries it’s pretty foolish to continue using Go
No matter if the language is Great or bottom line worse if there’s no ecosystem and libraries to promote productivity is all moo, hey we hate JavaScript but before I think of wasm I would have written most of what I want in JavaScript, this is why Go was so productive that it took just 5 years since it’s creation for the software tech world to feel the impact, that’s why rust ecosystem pushing for more high level library sugaring or “one click convenient macros” and I kinda like where ocaml is going it really needs to remove the tag “Jane street programming language”
Go has the ability to do what C or C++ can do to some extent while offering simplicity, easy to read and understand while rust gives you full control with its powerful type system because of that those complicated things can just be wrapped around someone’s library or function (.unwarp, .clone, Rc, Arc) coupled with rust ability to span in different domains of programming, rust will be compared to higher programming languages
Here’s the problem about languages like Rust, at the very beginning of rust goals it gives you all the control while offering security and performance, want some libraries to manage some these authorities no problem, but the problem here is that if everyone want to agree one thing or feature while the language gives the programmer to full control this causes fractions in the ecosystem, 3rd party vs rust core team issues and co, a single unmaintained library can deal a massive blow to the ecosystem on like Go where “The Language makes the decision for you” it gets worst as rust isn’t a domain specific language (way more than python or java) even tho it’s a systems language this brings in different domain ideologies into the language which in turn creates massive 3rd party libraries to be able to handle those ideologies which in turn causes a massive blow to the ecosystem if more unmaintained libraries pile up.
This circle will repeat its self over and over again
So whats your point ?,
old ideas never die ?,
language design is not language purpose and goal ?,
they made a mistake creating Go ?,
refusing to find something suitable or just break compatibility?
Well kinda, there’re indeed some services can cost more hosting than cloud hosting especially when it comes to geo-location, auto scaling, preventing dead servers but there’re are companies that maintain data centers, etc it depends
I was using docker swarm cause of the simplicity and easy setup but the one feature that I really really need was to be able to specify which runtime to use, either I use runsc (and docker plugins don’t work with runsc) or runc as the default and it was too inefficient to have groups of node with certain runtime, I really do like swarm but it misses too much features that are important
gcc-go, gollvm there’s actually no difference in comparison to the go compiler, heck in some cases gcc-go perform worse, Go internals are built with a different mindset and architecture there’re certain features that’s can perform worse than just hard coded assembly
If this was 4 years ago I would say “fair enough” but now Go 1.21 ? This claim is no longer Valid, just like saying CGO is slow, just because one language uses LLVM or GCC doesn’t mean they have state of the compiler
Firescracker is good and all but if one wants to use it, one has to change its ecosystem, it’s communication with other servers, why change your entire ecosystem for one tool or just build a tool to fit your ecosystem, and really like the concept of firecracker-containerd but still need some modifications and also I wouldn’t expect Google to put their entire Cloud Run, App engine under the hands of aws (even tho it’s FOSS)