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?
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.
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.
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.
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).
It all seems to be using https://github.com/kubernetes/gengo
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.
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.
Any two type systems can be meaningfully compared. My comparison was exceptionally broad and seems perfectly consistent with everything you said.
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.
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.)
I have. Multiple times.
> Deny it all you want. I don't really care to get into a definitional war with you.
You're not making your case, making me assume you don't have one.
> Weaker type systems permit this form of autoconversion.
Proof that the type system I'm talking about isn't weak, unlike the ones C and Go have.
I also don't appreciate being downvoted for having a pleasant discussion relevant to the topic.
> 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.
There are lots of type system features in Algol variants that you cannot express in Go.
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#)
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.