We have shipped unikernels for the last decade. Zero sec issues so far. I highly recommend looking into the unikernel space for a docker alternative. MirageOS being a good start.
cool! What services have you shipped as unikernels? Docker doesn't have to be an alternative; it can help with the build/run pipeline for them too: https://www.youtube.com/watch?v=CkfXHBb-M4A (Dockercon 2015!)
>You can pretty much replace "docker build" with "go build".
I'll tell that to my CI runner, how easy is it for Go to download the Android SDK and to run Gradle? Can I also `go sonarqube` and `go run-my-pullrequest-verifications` ? Or are you also going to tell me that I can replace that with a shitty set of github actions ?
I'll also tell Microsoft they should update the C# definition to mark it down as a scripting language. And to actually give up on the whole language, why would they do anything when they could tell every developer to write if err != nil instead
Just because you have an extremely narrow view of the field doesn't mean it's the only thing that matters.
Go is just one language, while Dockerfile gives you access to the whole universe with myriads of tools and options from early 1970s and up to the future. I don't know how you can compare or even "replace" Docker with Go; they belong to different categories.
In some situations, yes, others no. For instance if you want to control memory or cpu using a container makes sense (unless you want to use cgroups directly). Also if running Kubernetes a container is needed.
You have to differentiate container images, and "runtime" containers. You can have the former without the latter, and vice versa. They are entirely orthogonal things.
E.g. systemd exposes a lot of resource control as well as sandboxing options, to the point that I would argue that systemd services can be very similar to "traditional" runtime containers, without any image involved.
Rust has nothing new (even the lifetime stuff is copied) really. It just marketed itself really well. It got a huge number of migrants from JS/TS ecosystem, and python, and some from the C(+*) ecosystems.
Its a good language dont get me wrong, but also a huge pita to work with.
> Rust has nothing new (even the lifetime stuff is copied) really.
Rust has nothing new by academic standards, and this is an explicit goal of the project. (And that's why it has yet to support e.g. Haskell-like higher-kinded types; or dependent types for compile-time programming: the interaction with its low-level featureset is very much an open question.) It's incredibly novel as a production language, of course.
It has nothing new but they did a good job at cherry picking what what nice in other languages.
Which makes it an interesting language to learn actually. I even feel like Rust can even be a superb first language to learn for a new programmer : that’s a journey for sure but it would expose you to most of the modern programming concepts.
Saying it has nothing new seems like an uncharitable take. Yes, it has influences (that rust docs dedicate a page to [0]), but PL theory has such a rich body of literature that you can make a similar claim about virtually any language. It's the whole package that matters, and I don't think there's anything "rust but earlier" to point to there. Certainly isn't Ada.
We had many languages that are faster that are not c/c++.
Compare Go (esbuild) to webpack (JS), its over 100x faster easily.
For a dev time matters, but is relative, waiting 50sec for a webpack build compared to 50ms with a Go toolchain is life changing.
But for a dev waiting 50ms or 20ms does not matter. At all.
So the conclusion is javascript devs like hype, and flooded Rust and built tooling for JS in Rust. They could have used any other compiled languge and get near the same peformance computer-time-wise, or the exact same time human-timewise.
Anyway, you posted about speed, and then followed by a link to some python related thing. In python speed has never been a key tenet, at least when it comes to pure cpu based calculations. How much tooling is built in python? All the modern python tooling is mostly Rust based too. So theres that.
I mean for a dev working in JS with JS built tooling the speed is not in milliseconds, but in seconds, even minutes.
I still think my point holds, having a build take int he 10s of seconds vs 50ms is very much good enough for development (the usual frontend save and refresh browser cycle)
reply