Every CI system I've used at Tesla, Bun, and mesa.dev has had the same problems: stateless and slow (GHA), or stateful and horizontally unscalable (Jenkins), with YAML on top of either. The straw that broke the camel's back for me was the realization that all my Claudes are waiting upwards of an hour. So I quit my job to work on harmont, which aims to solve all of these pain points I've had.

In its current state, the project is very similar to Dagger in spirit with the core difference of harmont having what I believe to be a more pleasant API as well as being smaller in scope.

I'm looking for opinions and feedback. What might be the most interesting with the CLI is the DSL -- I've tried to make it ergonomic and friendly. To get started:

  curl -fsSL https://get.harmont.dev/install.sh | sh
  
  mkdir foo
  cd foo
  uv init
  cat >> pyproject.toml < .harmont/pipeline.py < PythonToolchain:
      return hm.python(path=".")
  
  @hm.pipeline(
      "ci",
      default_image="ubuntu:24.04",
      triggers=[hm.push(branch="main")],
  )
  def ci(project: hm.Target[PythonToolchain]) -> tuple[hm.Step, ...]:
      return (
          project.test(),
          project.lint(),
          project.fmt(),
          project.typecheck(),
      )
  EOF
  
  hm run

What's coming next:

  - COW filesystems: In a future release of hm, we mount FS layers on top of preceding layers, copy-on-write. I ran some experiments and they resulted in up to 40% faster runs on `uv run ruff`-style commands.
  - Development containers: `hm dev` enables you to spin up your application in however many instances you need -- if you have a local application, there is nothing stopping you from spinning it up once, twice, or 10 times.
  - The cloud: In parallel to the CLI, I've been working on the cloud, which I am hoping to private-access release in the coming month. It follows the same model as the CLI, but uses a very different execution engine (supporting RAM caches too, for you Bazel enjoyers =).
  - Additional language SDKs -- The private-access cloud is written in Haskell, Elixir and Rust. We already have harmont rules for Rust (which I would suggest you check out in Harmont's very own dogfood pipeline: https://github.com/harmont-dev/harmont-cli/blob/main/.harmont/ci.py), but we're adding more languages!
  - Plugin system: I recognize that not everyone will want to join the Harmont cloud but may find some utility in the Harmont task runner. At some point, I had a plugin system in place that allowed you to download and use harmont without any cloud-specific bloat, but unfortunately I tore that out, because the code wasn't great. Definitely working on bringing that back.

PS: I've gotten questions about the name. It is a reference to https://en.wikipedia.org/wiki/Roadside_Picnic (awesome sci-fi book, worth a read =) )

Comments URL: https://news.ycombinator.com/item?id=48296828

Points: 12

# Comments: 1

Additionally, fault-tolerant languages such as Erlang/Elixir allow me to not worry about the billions of edge-cases, and let Claude aggressively implement a mostly good-enough application. With LLMs, accepting a limited amount of failure may be a necessity (depending on the business/domain), and that's exactly what the BEAM enables.

Totally recognize and agree with the lack of libraries -- that's really Elm's weakest side.

For example, https://harmont.dev's app (landing page is not Elm) has a component to render a pipeline graph called DagGraph. In React, you'd do something like

  function DagGraph() {
    const steps = useState([]);
    const selectedJobIdx = useState(null);
    return ...;
  }

  function DagGraph({ steps, selectedJobIdx } : IDagGraphModel) {
    return ...;
  }

  function PipelinePage({ graphMode, selectedPipeline }: IPipelineModel) {
    return (
      graphMode === GraphMode.DagView
        ? 
        : 
     );
  }

  namespace PipelineState {
    interface Model {
      steps: Step[];
      selectedStep: number | null;
    };

    interface ISelectStepMessage { stepIdx: number };
    interface IUnselectStepMessage;

    type Message = ISelectStepMessage | IUnselectStepMessage;

    function update(m: Model, msg: Message): Model { return...; }
  }

  // main model
  interface Model {
    pipeline: PipelineState.Model,
  }

  type Message = PipelineState.Message | SomeOtherMessage | ...;

  function update(m: Model, msg: Message): Model {
    switch (msg) {
      case PipelineState.Message as msg:
        return update(m, msg);
      ...
    }
  }

At the end of the day, there's a trade-off -- my logic is no longer localized to the "component" relevant to rendering the pipeline DAG. I never have one file open editing Elm code, but I'm a vim user so it doesn't bother me. In some ways, semantically, I think it makes sense to split the "state backend" of your UI from your UI, in my opinion.

Most of my app states are represented as state machines (coming from embedded this is quite natural) and UI is represented as pure transformations of that state.

With Elm, it really feels like you reason about state and UI separately, and I actually prefer that, both for testability and that's just how my brain works.

Apologies for the spam!

I'll put it on the list of things for the next release! Thanks =)

Sonny brought me so much joy in life. I found these fun stories https://www.syncopatedjustice.com/p/three-sonny-rollins-stor... about him and I'll quote one here:

> One day Sonny and Max Roach were walking down Seventh Avenue in New York and a man approached them. “Max, what’s the most important city in the world,” he asked. > > “New York.” > “No, that’s not it.” > > Max paused for a moment and then responded, “Paris, the City of Light.” > “No Max, what is the most important city in the world?” > > Max turned to Sonny and asked, “Do you know?” Sonny shook his head no. > “Alright, I give up, what is the most important city in the world?” > > “Generosity.”

He didn't have an easy life, and definitely wasn't a daisy himself, but he was a damn good musician and brought so much happiness.

Templates in C++ benefit from being part of the core language, -- stick a `template` above your `class`, and you're in metaprogramming land. Stick a template specialization, and you've done a niche optimization. You didn't need a separate crate or a whole macro DSL. Variadic templates are also really really nice for monomorphizing N-ary generic functions. The duck typing of templates makes

This is precisely where I struggle with Rust the most -- monomorphization is limited within generics, so you end up going to the `proc_macro` hell, which involves a separate crate, a separate Cargo.toml, etc.

Zig seems like it would fit the bill -- and doing micro-optimizations within zig is surprisingly easy. The language's comptime facilities allow for really good niche optimizations -- however, the language also has some strange decisions. The allocator interface is notoriously a vtable, so a lot of the DOD optimizations that andrewrk has spoken numerously of (and to be clear -- I did learn a lot about DOD from his talks back when I was a wee engineer), raise one of my eyebrows.

C seems like it should be fast, but implementing any data structure, any generic algorithm in C is impossible. Either you're copy-pasting, or you're making macro DSLs. None of which is great.

---

To further talk about the C++ situation -- the monomorphic allocator interface was always awesome. Compared to Zig's vtables and Rust's nothing (up until a couple days ago), having a way to pass custom allocators with types was awesome. The new std::pmr::* interfaces and containers are also really exciting -- monomorphization, as beautiful as it is, does cost a lot -- refactoring it is not easy, compilation times are a mess. Sometimes the right tool is a vtable interface, and, C++ gives you those facilities.

And this is C++'s no1 problem when it comes to performance too -- it's a leviathan -- it'll give you the tools to write REALLY fast code, but it will also give you inheritance -- forget about your caches then.

When I was working at Tesla, there were some pretty gnarly vtable jumps in firmware (of all places), and I suspect part of that could've been alleviated if people knew more about CRTP.

So, here's where I land -- C++ really will give you the tools it can to let you write the fastest code possible. But it will also give you the tools to make your code really slow. Committee language means everyone in the committee needs to be happy.

Rust, on the other hand, is really designed to promote safe-but-very-fast practices -- had the firmware that I discussed used Rust, my guess is that we would've gravitated towards generics and monomorphization, rather than the heavy dynamic inheritance. C++, when it comes to performance, as it does to all other things, is a barreled shotgun. Rust's design almost always promotes the best available pattern and that's why I rarely reach out for C++.

Unfortunately, React's biggest problem is that it forces you into the JS/TS ecosystem, which is, without a doubt in my mind, a compilation target rather than a system I wish to interact with natively.

I'm happy with Elm -- the community is really small, and sometimes you have to roll your own libraries. TEA is sometimes... unnatural (coming from React), but the fact that you do not have to worry about implicit and unexpected state (see useEffect), I always get excited to work with Elm.

Additionally, Claude seems to manage itself better in Elm than in React, at least within large, scary codebases.

At the moment, no. I'll ad this to the list of features for 0.2, totally slipped my mind, and if I remember correctly, both napi-rs and pyo3 have support for this.

> - It seems like all #[hsrs::function]s are translated to return IO (since Rust functions can do arbitrary side effects). It would be great if you could (unsafely) mark functions as pure, to get pure Haskell functions without having to wrap them in unsafePerformIO.

I did think through this a little bit and couldn't find a good way to implement this so decided to delay it until the next release, until I come up with some better ideas.

I wanted some sort of automated mechanism to determine purity, but that, obviously, doesn't exist in Rust. There _are_ some ways to approach this -- `const fn` are pure (I think), and it would be cool if I added support for https://github.com/creusot-rs/creusot. I was thinking of walking down the AST of a function to automatically infer purity, but that seems like a whole other, order-of-magnitude larger project. I'm still not sure what to do about this (bar a simple annotation), but I'll land something for 0.2. https://github.com/harmont-dev/hsrs/issues/1

> - Both Haskell and Rust have HM type systems, so I wonder if you could also translate type classes from Rust to Haskell.

Yes!! I do think that would be quite neat and I spent a little bit of time thinking through it, but I couldn't really come up with a great use-case (at least for my needs) that justified the necessity of this feature. This _might_ (probably won't) land 0.2, but it's definitely something I'm thinking about. One of the big problems that makes this quite non-trivial is monomorphization -- it's unclear what kind of specializations of a particular generic function you want in Rust. Trait objects _should_ be able to work, but I still haven't figured out the details of all of that. https://github.com/harmont-dev/hsrs/issues/2

```cpp JSC_DEFINE_HOST_FUNCTION(jsMyFunction, (JSC::JSGlobalObject* globalObject, JSC::CallFrame* callFrame)) { JSC::VM& vm = globalObject->vm(); auto scope = DECLARE_THROW_SCOPE(vm); ... ```

kind of the same thing, seems like -- passing data around to be managed by the GC.

I couldn't really find any bindings generator that would create type-safe, rich bindings for Haskell from Rust. Naturally, both languages have rich type systems, so I was amazed that no awesome bindings generator already existed, hence I decided to write my own. hsrs feels very similar to pyo3 and napi-rs, and if you've used those, hsrs will feel right at home.

What's unique about hsrs as opposed to hs-bindgen is that it has type-safe bindings for rich types, like Result, Maybe, etc. while also generating Haskell bindings. The repo contains a minimal example, and more details are available in the haskell discourse: https://discourse.haskell.org/t/ann-hsrs-ergonomic-haskell-b...

Comments URL: https://news.ycombinator.com/item?id=48189044

Points: 53

# Comments: 9

> Klabnik vibe-coded a new language in Rust, therefore Claude + Rust = Good.

I argue the inverse -- Rust, being an ML-family language, is well suited for parsing, and language design (I know! Shocker!). In more moderate translation -- ML-style languages are good for parsing, interpreting and compiling code. Claude is not the magic here -- ML is.

I would also add that I've had decent success vibe-coding+human-coding Haskell (contrary to the article). My experience is that if I can hand-write a rich set of types (blessed be IxMonad), I can throw Claude to fill in the blanks for the implementations. If I can design the data structures that make the program tick, bridging them is something Claude is awesome at. Again, no surprise -- it's intern-level work.

The key distinction between C, Zig and Rust is that Rust is designed around types. C and Zig are more memory-oriented -- they really see most of your program as flat memory and you can kind of shoehorn a little bit of data layout in that flat memory. While this offers a large amount flexibility, this philosophy isn't well suited for proving out correctness. But again -- this doesn't mean they don't have a spot.

When I was a junior at Tesla, I used to joke that senior staff had a VMs in their heads, because that's really how you analyze C programs -- you try to execute it in your head, with interesting inputs, but that's about it. Claude's head-VM is quite fuzzy and often makes errors.

With Rust, if you design your type system, you prevent yourself from making dumb mistakes. Swap out "yourself" with Claude here and it's the same story.

I've yet to see Claude design really nice type systems, fwiw.

But the point is -- Claude is the enemy of beauty and correctness -- it's up to the SWE to design a type-system which will prevent it from doing so. To be clear, I obsess over type-systems personally, but that's not the only way -- incredibly rich, comprehensive, huge type systems, fuzzing, Antithesis, proptesting are all things you can do to minimize the impact of slop, and those are all valid things to do.

---

> Code is not written by humans therefore it doesn't matter that you don't know Rust.

Wouldn't say this was explicitly stated, but I definitely smelt this undertone throughout the article. If you don't understand the language you're reading, how can you understand whether the code in front of you is correct or not? If you have a systems engineer sitting across you to clean your PRs up, you can pass that responsibility onto them, but what about when they give their two weeks?

If all you know is Python, chances are you're going to make better software in Python than in Rust. Stick an `Arc>` everywhere and chances are your code will be slower, as a matter of fact. Use If you want to learn Rust, please join us! But if all you're trying to do is vibe-code better code -- do it in the language you know and can actually debug when shit hits the fan.

---

> Anthropic C Compiler

It is impressive that Claude is awesome at taking existing code and rewriting it, this is certain, but I'd like to repeat the exact same rhetoric that many have given -- rewriting =/= original authorship. Awesome, we have a C compiler, but we already had one, and we just rewrote it? Seems like a little bit of wasted electricity.

To build on top of this, I am really happy that Bun is exploring Rust, and the Claude rewrite is truly impressive, but quite surprising at times, preserving strange anti-patterns (my name being said anti-pattern, teehee): https://github.com/oven-sh/bun/blob/ffa6ce211a0267161ae48b82.... It's hard to determine why Claude decided this -- I assume a really strict input prompt.

Do note that the current stage of that PR is much better than what it was at the state of that commit, and obviously Jarred isn't merging blind slop, but that is still human-driven by someone who has an understanding of their product.

My bet is actually that _rewrites_ of already-functioning, well-tested code, are likely to be more common as time progresses. I think that's what Claude is really awesome at, and I think Claude can often achieve 80-20 improvements through rewrites. Again, Claude alone will not be a silver bullet -- it won't generate data-oriented programs if the source material wasn't data-oriented. It won't optimize for cache coherency, if the source didn't, but moving from Python to Rust alone, with more-or-less the same code structure, you're likely to see improvements by virtue of common operations being memory-coherent and avoiding the GIL and so on.

---

> A C compiler written in Rust used to be a graduate thesis. It isn’t anymore.

Come on, this is disingenuous -- a simple C compiler is a 1-day long project. LLVM is a graduate thesis (and for good reason). Copy-pasting prior-art is academic dishonesty and Claude does a lot of that.

---

For transparency: I work with Noah.

EDIT: Wanted to add that not a single line of my comment was AI generated.