5 ms·
There you Go (pun intended). Go even replaced a low-level language like C++ and achieved the same result in the end. I don't know why I thought it's Java, proba
by johnnycerberus 5y ago
There you Go (pun intended). Go even replaced a low-level language like C++ and achieved the same result in the end. I don't know why I thought it's Java, probably the first Kube was initially in Java. It's even better that they managed to pull that off.
- tazjin 5y agoBut it did not replace it. Google runs on Borg. Go lets you build things fast, but the lack of strong typing and the vast amount of language pitfalls make maintenance hard in the long run. The community also has the attitude to pretend that these pitfalls don't actually exist, which is very different from C++ where most peculiar behaviours are well-understood and controlled.
- johnnycerberus 5y agoSorry, I don't think I have been explicit in my comment. The language of K8s, a system which is the so-called direct descendant of Borg, replaced C++ at that layer. Also, Go is strongly typed.
- mijoharas 5y agoI'd argue that go is statically typed rather than strongly typed due to `interface{}`. > There is no real agreement on what "strongly typed" means, although the most widely used definition in the professional literature is that in a "strongly typed" language, it is not possible for the programmer to work around the restrictions imposed by the type system. This term is almost always used to describe statically typed languages. (random definition found googling).
- still_grokking 5y agoActually Google knew at the time they "designed" k8s that Borg doesn't scale due to fundamental design flaws in it's basic architecture. Still they reused the exact same architecture for k8s. Who wants to know the details of those scaling issues can google for the Omega paper. The "proper"™ solution to those design flaws was implemented in Mesos (and to my knowledge nowhere else until now).
- ksec 5y ago>The "proper"™ solution to those design flaws was implemented in Mesos And yet somehow Mesos failed... sigh.
- still_grokking 5y agoBecause the market never chooses the most advanced technology. It chooses the (perceived) cheapest thing with the best marketing. Always.
- hnlmorg 5y agoI've had just as many problems maintaining mature C++ projects as I have maintaining mature Go projects. Ultimately it all boils down to two things: - The projects being well written and well maintained from the outset - Personal preference I cannot overstate that second point. It really is about time developers stopped pushing their own personal preferences as if it's some kind of fact.
- pdimitar 5y ago> It really is about time developers stopped pushing their own personal preferences as if it's some kind of fact. Agreed, so let's all go to Rust or OCaml because they have very strong static typing systems. ;) Both C++ and Go have plenty of warts, with C++ having way too many footguns and Go allowing you to use it as a dynamic language whenever you figure it's too much work to go through your problem with static types.
- still_grokking 5y ago> Agreed, so let's all go to Rust or OCaml because they have very strong static typing systems. ;) Seems very reasonable. Especially OCaml should get more of the praise it deserves. If you need to stay on the JVM there's Scala which allows (with some discipline) to write "when it compiles it works" code.
- hnlmorg 5y agoYou've very much missed the point of my post. But from the tone of your reply, I sense we'd never see eye to eye anyway.
- wbl 5y agoWhich human do you think understands C++?
- farresito 5y ago> Go even replaced a low-level language like C++ and achieved the same result in the end Did it, though? Honest question. I get the feeling that it ended up competing with Java (and Python) more than it ended up replacing C++. The C++ folks seem to be way more into Rust than Go.
- johnnycerberus 5y agoI'm a Java fan and an ex-Scala aficionado. I would have hoped that JVM would eat the pie when it comes to cloud deployments but it didn't happen. Like Scala.js never happened and TypeScript became the type system of the web. JVM languages will remain at the application layer, concerned with microservices, data processing, streaming, databases, etc. It's not what folks seem to be way more into, it's all about tradeoffs. I am talking here about layers and the suitability of a language at a specific layer. I don't know about Rust, but Go proved that it can handle it. If Rust would prove to be better, that would be great, but only time will tell. Until now it did not happen, instead people are trying to fit Rust in scenarios where a higher-level language would go round in circles (GUI programming, microservices, game development etc.). For Java it is too late, if GraalVM with native images and value types would have been released earlier, maybe we could say that Java could compete with Go at that layer, but it is not, the train has left the station long time ago. Only if Oracle comes out of the cave and throw a lot of money at a JVM alternative to Kubernetes, which is likely to happen in the foreseeable future, given the investments and the attention the Java platform has received recently.
- EdwardDiego 5y agoPlenty of K8s operators written in Java. Sure, it's not not underpinning K8s itself, but tbh, what language K8s is written in doesn't really matter, so long as it works.
- johnnycerberus 5y agoYes, exactly my thoughts, the problem is that devops generally are used to Python/Go and in my company though they don't make it mandatory, they recommend Go. Also, they have a repulsive reaction to everything .NET and JVM :).