Kubernetes, Swarm, and Mesos can all technically schedule jobs for you and handle constraining resources for you.
Unlike the other two, Mesos was designed primarily to handle distribution, task, and resource management at a lower level. Focusing on these bits led to greater power and flexibility, but also more complexity at a lower level. That's why DC/OS exists, to give you a bundle of microservice tools that work well as a higher level platform.
Mesos was also designed to allow you to bring your own scheduler to handle task lifecycle needs, which tend to be needed for stateful tasks. Kubernetes and Swarm were designed primarily to handle the stateless services use case and then adapted later to handle stateful services and jobs, with the included scheduler.
DC/OS is built on Mesos and comes with built-in schedulers for jobs and services, while still allowing you to build your own custom scheduler if needed.
Kubernetes recently added support for custom schedulers as well, but its significantly less mature than the Mesos implementation and ecosystem and also still revolves around using the core pods & replica set primitives, which may be empowering or limiting, depending on your needs.
Mesosphere recently built a new dcos-commons framework to make it trivial to build JVM-based Mesos schedulers, as well. So that may boost your productivity on DC/OS. https://github.com/mesosphere/dcos-commons
Mesos & DC/OS also gives you more options on containerization. You can use Docker images and Docker containers, if you like. Or you can use the Mesos container runtime with or without Docker images, which gives you more flexibility in terms of workloads and packaging.
DC/OS and Kubernetes both have package managers, as well, which can be useful for installing dependencies like Spark, Kafka, or Cassandra. But DC/OS tends to have more robust data services, because they're built with their own custom schedulers, whereas the Kubernetes ecosystem tends to make complex lifecycle managing Docker container wrappers around their systems due to the late arrival of custom schedulers. Docker also sort of includes package management if you consider docker images "packages". The difference is that DC/OS and Kubernetes package higher level abstractions (apps & pods) which may include multiple containers. More recently, Docker has added "stacks" which are higher level abstractions, but I don't think there's any external repository mechanism or much package management around them.
Swarm is definitely the simplest, but its original API was designed to be the same as the node API, which was great for familiarity and onboarding, but rather limiting as a higher level abstraction. They've since effectively rewritten the swarm API and bundled it into docker-engine as "swarm-mode". This bundling of the orchestration engine and container runtime makes it easier for the user to install and manage but also combines what was previously two different abstraction levels. So instead of being just a dependency of orchestration engines, Docker engine now competes with them as well, going against the unix philosophy of doing one thing well and making for a bit of a political mess in the respective open source communities. Twitter, hacker news, and chat conversations escalated into talk of forking docker which lead to K8s experimenting on alternatives, DC/OS supporting Docker images without using Docker engine, and Docker extracting containerd.
They all work fine. Selecting one kind of depends on your needs. I generally recommend DC/OS because it tackles a larger set of problems and is made up of many distinct microservice tools and layers, allowing you support multiple use cases by programming against the layer than makes the most sense. Disclosure tho, I do work for Mesosphere! ;)
swarm(old)~=swarm mode(new in docker 1.12). "bundling swarm" is oversimplifying the recent changes to the docker engine as it was a complete overhaul to include more features and make it easier to deploy and manage (with a cluster API). Also "with mixed results" and "unhappy orchestration partners" is subjective and needs sources for the claim (user survey). It is not really useful to the answer and makes it look biased. Editing the answer to be "neutral" would go a long way towards making the answer more credible :) (disclosure: I used to work for docker) – Shaunteshave