How does this compare with Heroku's buildpack system?
Habitat — A new approach to automation
51–57 of 57 posts
Re: Habitat — A new approach to automation
#52Earlier quoted context omitted.
Could you elaborate a bit more on why you chose Rust, and why you think it was the right choice for this project?
On the heels of this, I've been exploring Rust a bit lately but haven't been able to find any solid patterns / style guides for idiomatic Rust. Do any such resources exist? For example, the official rust book describes Arc, Mutex, etc but.. Are there more of these in the standard library? What purpose do they serve? What are some good idioms to apply when using them? I can surely make them work, but maybe I should be…
You might want to join users.rust-lang.org.
Like most languages idiom is learned while working with the language. Something I've found for instance is to try and use Iterators to get around sharing rules as they can encapsulate sharing patterns in a lot of cases.
The specific modules you mentioned are for multi-thread support, those are only necessary for sharing memory between threads.
Anyway, I think this is off-topic for this thread.
Re: Habitat — A new approach to automation
#53Earlier quoted context omitted.
This is Adam - Rust has been amazing to work with, and was the prefect choice for this platform. It's great.
Could you elaborate a bit more on why you chose Rust, and why you think it was the right choice for this project?
Sure. Habitat's supervisor is a very low-level thing - it manages the lifecycle of your service, participates in the gossip ring, etc. That means a failure at runtime of the supervisor is pretty unacceptable, and similarly, you don't want anything (like a long GC pause, for example) to get in the way of the supervisor doing what it needs to do.
Rust gives us 3 things we needed, and it says so right on the website: fast, no segfaults, thread safety. Additionally, it's community is top notch. We've found the language to be great to work with, especially when you're refactoring. The type system makes it clear where it's possible for the code to fail, making it easier for us to reason about keeping the supervisor safe.
I wrote this while I was evaluating languages for the early habitat prototypes: https://medium.com/@adamhjk/rust-and-go-e18d511fbd95#.d35imt...
Best, Adam
Re: Habitat — A new approach to automation
#54Earlier quoted context omitted.
So basically it "does not work"...
Well, let's be clear, if it doesn't work, you know at compile time, not at runtime. I don't care how broken things are at compile time if I'm guaranteed that everything will work at runtime. That's kind of the whole point of nix. It's not impossible to write code with errors, but you should not be able to build as long as the errors exist.
Also, it does work. It's just not completely automatic.
Re: Habitat — A new approach to automation
#55I watched the videos, did the tutorial, read the docs, read the tech site stories but I still don't see why I would use Habitat over the current Docker workflow and ecosystem (including third party) for building, shipping and deploying applications. Both are a type of packaging that puts the application, its dependencies and configuration in a bundle that can run exactly the same everywhere. Docker has Dockerfiles and docker-compose.yml files, Habitat has plan files (seems like a shell script, Dockerfiles and compose files are much simpler). Docker has a central repository/registry "docker hub", habitat has depots. "docker run redis" == "hab start core/redis", etc... etc...
The docs/articles say habitat apps can run in containers, but why bother if your app can already be run in a container that achieves the same thing with even greater isolation (cgroups). Why put a self contained app in a self contained container application?
I'm not trying to put down Habitat, I'm trying to understand its role. As I currently see it, why would I choose this over the more mature Docker environment with a massive established ecosystem and user base?
Again I'm just trying to understand what I'm missing, if I'm missing something please point me in the right direction.
Re: Habitat — A new approach to automation
#56I watched the videos, did the tutorial, read the docs, read the tech site stories but I still don't see why I would use Habitat over the current Docker workflow and ecosystem (including third party) for building, shipping and deploying applications. Both are a type of packaging that puts the application, its dependencies and configuration in a bundle that can run exactly the same everywhere. Docker has Dockerfiles and docker-compose.yml files, Habitat has plan files (seems like a shell script, Dockerfiles and compose files are much simpler). Docker has a central repository/registry "docker hub", habitat has depots. "docker run redis" == "hab start core/redis", etc... etc...
The docs/articles say habitat apps can run in containers, but why bother if your app can already be run in a container that achieves the same thing with even greater isolation (cgroups). Why put a self contained app in a self contained container application?
I'm not trying to put down Habitat, I'm trying to understand its role. As I currently see it, why would I choose this over the more mature Docker environment with a massive established ecosystem and user base?
Again I'm just trying to understand what I'm missing, if I'm missing something please point me in the right direction.
Re: Habitat — A new approach to automation
#57Is this like Docker?
Rather like nix + consul.