I was introduced to the Kubernetes source code by an Redhat Kubernetes Core Contributor. He showed me the nasty parts how they solved the lack of generics. Actually they use strings to concat valid go source code based on reflections. A little tedious but given the constraints for language choice they had (fast, compiled binary, close to the metal) I think Go is still a decent choice for Kubernetes.
Kubernetes is literally the Angular of orchestration systems. SwarmMode is so much cleaner and less complex to use, dive into, and hack on.
I'm unsure why the community rallies behind Kube considering it's insecure, horribly complex, and a PITA to configure. I guess because google lied and said they use it internally, even though they're still using Borg?
If by "the Angular of orchestration systems" (I'm going to assume Angular 1 because Angular 2 gives me headaches still) you mean that it's really easy to do what should be easy, and feasible to accomplish really complex things, then I would agree. But I don't think that's what you meant.
As far as security, that's now purely a property of the way you deploy it. Secrets can be encrypted (feature in alpha), RBAC is fully supported, TSL client certs are preferred for AuthN, and HTTPS is supported across the API endpoints. I'm not sure what more you could ask for on the security side.
I don't know that Google says they're using K8s internally, either. It's always been sold by Google as a ground-up rewrite of what the authors wish Borg would have been. Not only that, but it's supported (developed) by dozens of small companies, as well as Google, Red Hat, and an increasing number of large companies interested in its growth.
Finally, it's governed by the Linux Foundation. If there's another org that can help scale and properly govern one of the most popular modern OSS projects, I'm drawing a blank.
Well for one Swarm was released a year ago and Kubernetes went 1.0 two years ago, so there has just been more time for people to get familiar with k8s. I myself dug into kube before Swarm arrived and have put off getting into Swarm because constant framework hopping kind of defeats the purpose of getting familiar with a new framework in the first place.
While I agree to some extent re complexity, I'd be interested as to what you're referring to when you say kubernetes is insecure.
Sure, I could definitely get a swarm set up quickly and run something trivial on it, but then I'll be back to the docs for secrets, stateful containers, volume mounts, cert management, instrumentation, health checks, load balancing etc.
My point about 'framework hopping' was that I try to get some value out of the time spent digging into a new tool/library/framework, rather than trying to use something new for each new project. Knowing the pitfalls, useful configs, edge cases, best plugins and so forth goes a long way towards being able to focus on what you're actually building. I'm not against early adoption and I am always learning new tools, but I do try to leverage the ones I have deep knowledge of.
> I'll be back to the docs for secrets, stateful containers, volume mounts, cert management, instrumentation, health checks, load balancing etc.
Almost all of your points are on one page in the doc (just google 'docker-compose file') which is read and used in 5 minutes. Btw, load balancing is the default, no real config required (still you can but the defaults are sensible). Anyway, you are usually 5x to 10x faster than with setting up an k8s cluster. This should be a good enough reason to give it a try and to make your own picture of Swarm.
It is up to you but I think you have a wrong picture of Swarm. Something huge, conplicated and intimidating like k8s. Something you should spend your weekend and the week after to learn. This is wrong.
Just see is as another CLI tool which you can grasp in the next hour (instead of surfing the web).
Borg has so many knobs that Kubernetes still lacks (or always will, by design), but there are already unspecified Google projects running on Kubernetes.
Just getting back into Go (was Clojure), missing generics were annoying indeed. Though doing things with strings in source isn't fundamentally different from type erasure in the JVM (can wiki the term). Ie. Generics in Java are strings in the source code that don't make it through compilation either, Java just has explicit syntax for it and IIRC C++ templates generate a collection class for each type.
As one of the perpetrators of gengo, we focused on simple, fast, and dirty. We wanted something a little higher level than Go AST to deal with types (for gen), and we knew we wanted to gen a ton of code.
Some of the Kube code generation would not be solved by generics (or at least, not obviously) such as our API conversion logic which defines arbitrary transforms between structs and generates the rest. The others (proto, defaulting, etc) would.
Go isn't particularly fast or close to the metal as compiled languages go - I feel like a lot of people compare it against scripting languages but those aren't the only alternatives. If GC is acceptable you have a wealth of mature languages available with a proper type system, e.g. OCaml.
Just the most well known ones, even if most of them are currently no longer used and failed the market for various reasons.
Algol-68RS, CLU, Mesa/Cedar, Oberon, Oberon-2, Oberon-07, Active Oberon, Modula-2+, Modula-3, Eiffel, Component Pascal, Swift (RC is a GC algorithm), Standard ML, MLton, Sing#, System C#, .NET Native (VB.NET and C#)
Does Go have a strong type system, or does it have an Algol-style type system? I'm pretty sure it's the latter, unlike OCaml and Haskell. It's competing with C++, in other words, so there's your basis for comparison.
Go's type system is "strong," as far as that goes. In comparison to OCaml and Haskell, Go's type system is less expressive. That is, OCaml and Haskell will let you express more invariants in the type system more easily.
The point of a type system is to make it easier to reason about your programs, so a type system like C's, where almost all of the types are size specifications, like the difference between short and int and long, is almost orthogonal to the purpose of having a type system in the first place: It doesn't matter if someone's height in centimeters is an int or a long, it matters that it can't be added to their age in days, and if someone tries it, the compiler catches it and alerts the programmer to nonsense in the codebase.
Being able to represent both their height in centimeters and their age in days in a 32-bit integer is pointless trivia unless you're designing a bits-on-the-wire network protocol specification, or interfacing with hardware registers, or designing a binary file format, in which case C's type system still doesn't give you enough information, because endianness is not specified.
Object systems are an attempt at solving the "Foogols don't have real type systems" problem, but they drag in notions of hierarchy which don't always fit outside of toy problems, and not even then. Plus, Smalltalk-style object systems which mandate that everything must work via message-passing drags in even more complexity orthogonal to the idea of finally having a semantic type system. And as long as there are still size specification pseduo-types, boxed or unboxed, the type system still has an inherent hole in it, because you can still say nonsense which type-checks perfectly cleanly.
So saying Go has a strong type system and comparing it to OCaml or Haskell is meaningless, because the two kinds of type systems (that is, real, semantic type systems versus size specifications) aren't trying to do the same thing.
Your entire comment seems to be about C. But you asked about Go. C's type system is classically considered "weak" and Go's is considered "strong." This isn't controversial, insomuch as "weak" and "strong" have meaning in the first place. C will perform some implicit conversions between types for you. Go won't. That's the difference that causes one to be considered weak and another to be considered strong.
Any two type systems can be meaningfully compared. My comparison was exceptionally broad and seems perfectly consistent with everything you said.
My point is, types which specify low-level details about data size and representation but not the semantics of which operations are actually sensible to use on them and which types can be meaningfully used together are not really types, in that they don't make programs any easier to read or write.
I also deny that autoconversion weakens a type system. For example, if you have a data type which holds a person's height, it is utterly uninteresting what units it's in most of the time, and it can save a lot of trouble if the runtime or compiler keeps track and converts automatically if you try to add a height currently being stored as inches to one currently being stored as centimeters, or adding centimeters to fractional centimeters rounded to the nearest millimeter, for example. There are any number of purely mechanical autoconversion tasks which can and should be done automatically and which don't change the type, in that they don't change which operations are valid for the value. And that autoconversion still wouldn't make adding height to age any more sensible, even if the two values were truly indistinguishable at the machine code level.
> the semantics of which operations are actually sensible to use on them and which types can be meaningfully used together
Go lets you do this just fine. I think it would help if you used concrete examples to demonstrate what you mean.
> I also deny that autoconversion weakens a type system.
Deny it all you want. I don't really care to get into a definitional war with you. The definitions I use are the ones that have a consensus backing them[1]:
> in general, a strongly typed language is more likely to generate an error or refuse to compile if the argument passed to a function does not closely match the expected type. On the other hand, a weakly typed language may produce unpredictable results or may perform implicit type conversion.
If you read that article, you'll see that most of it is about describing what the terms mean. There is no precise definition, and I've been careful to embrace that fact in my comments. Nevertheless, in common usage, the terms "strong" and "weak" in the context of type systems typically demarcate the prevalence of implicit autoconversions between types.
> And that autoconversion still wouldn't make adding height to age any more sensible, even if the two values were truly indistinguishable at the machine code level.
Weaker type systems permit this form of autoconversion. Notice that "strong" and "weak" are properties of the type system itself, and that they refer to implicit autoconversions between types. Autoconversions that occur because of appropriate polymorphism defined by users of the language is an orthogonal concept.
I think the bottom line is that you aren't using "strong" and "weak" as they are commonly used. If you want to make up your own definitions for them, then please just say that so that we can stop wasting time. (I have no problem with you coming up with your own definitions, I just want you to acknowledge that you're doing it.)
You didn't use a single concrete example. Please show some Go code that demonstrates your point.
> I also don't appreciate being downvoted for having a pleasant discussion relevant to the topic.
I didn't downvote you (I couldn't even if I wanted to, HN disallows it). But you have certainly not made this a pleasant conversation. Your comments aren't intelligible to me. I've asked for clarification and you haven't given it, which leads me to believe you aren't interested in a good conversation.
> Proof that the type system I'm talking about isn't weak
I never contested that.
> unlike the ones C and Go have.
The only claim I've made is that Go's type system is "strong." You have, not once, ever responded to this claim directly.
Keep in mind that reference counting, which Rust supports in its standard library, is a also form of garbage collection. It may not be part of the core language, but then again neither are RAII in C++, monads in Haskell, and getters/setters in Java.
Yeah...no GC'd language is really close to the metal.
> I think Go is still a decent choice for Kubernetes.
After what you described, it sounds like the authors decided to double down on their choice and dig a deeper hole rather than use the right tool for the job.
