Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.

Mesos will Support Multiple Container Formats with the Unified Containerizer

Mar 14th, 2016 8:12am by
Featued image for: Mesos will Support Multiple Container Formats with the Unified Containerizer

Apache Mesos has been supporting Docker as an alternate to its own default container since late 2014. But now the popular open source cluster scheduler platform is nearing completion on a more simplified approach that intends to replace both of the two existing containers in the hopes of easing future development of frameworks.

In addition to this goal, this new “unified containerizer” will allow newer container formats to be much more easily added into Mesos. Projects like rkt, appc and any future workout of the Open Container Initiative are alternatives to the more well-known Docker format that will likely become more prevalent over time as each finds their niche use case.

When explaining their motivation for this change, the maintainers had this to say in a recent update to their documentation:

“Maintaining two containerizers is hard. For instance, when we add new features to Mesos (e.g., persistent volumes, disk isolation), it becomes a burden to update both containerizers. Even worse, sometimes the isolation on some resources (e.g., network handles on an agent) requires coordination between two containerizers, which is very hard to implement in practice.”

Unifying the Mesos containerizer simplifies the API called by schedulers like Marathon or Chronos, eliminating the need to constantly update the ecosystem as these new runtimes are added over time. Instead, the details will be abstracted from those higher-level frameworks, and implemented as image providers and runtime isolators.

This change means that adding support in your own cluster for a new container type would only consist of a few extra arguments to the mesos-slave service, a big step up from when the Docker containerizer was first introduced in Mesos. This new image provider abstraction would also allow for a wider array of options to deploy container images locally without the need for a Docker registry, which can be a pain point for small shops.

Even if this new addition gets added to the upcoming 0.28 release, seasoned users of Docker on Mesos may want to wait a bit before switching to this new method. At launch, there will only be support for the newer v2 Docker Registry API, and bridged networking won’t be supported either.

The use of private registries will also be a bit clunkier at first. Nevertheless, this marks another important step in maturing the container story on Mesos, and will position the platform to continue being viable and stable during an otherwise rapidly-paced period of the overall IT landscape.

Docker is a sponsor of The New Stack.

Feature image via Pixbay.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: The New Stack, Docker.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.