cube2222
Joined 10 years ago
Joined 10 years ago
Sounds like you found an excellent way of structuring this problem to solve it with Claude (for those who don't click into the article - writing hand/claude-optimized Rust code for each query, checking its assembly, and trying to make their own optimizer generate something close to that same assembly), and the writeup is very interesting and readable too!
Kudos, looking forward to more blog posts like this one.
That's a pretty big limitation, I would argue, unless I'm misunderstanding and it can be worked around easily somehow? I'm surprised it isn't surfaced more prominently in the comparison.
We're a VC-funded startup (recently raised $51M Series C) building an infrastructure orchestrator and collaborative management platform for Infrastructure-as-Code – from OpenTofu, Terraform, Terragrunt, CloudFormation, Pulumi, Kubernetes, to Ansible.
On the backend we're using 100% Go with AWS primitives. We're looking for backend developers who like doing DevOps'y stuff sometimes (because in a way it's the spirit of our company), or have experience with the cloud native ecosystem. Ideally you'd have experience working with an IaC tool, i.e. Terraform, Pulumi, Ansible, CloudFormation, Kubernetes, or SaltStack.
Overall we have a deeply technical product, trying to build something customers love to use, and have a lot of happy and satisfied customers. We promise interesting work, the ability to open source parts of the project which don't give us a business advantage, as well as healthy working hours.
If that sounds like fun to you, please apply at https://careers.spacelift.io/jobs/3006934-software-engineer-...
You can find out more about the product we're building at https://spacelift.io and also see our engineering blog for a few technical blog posts of ours: https://spacelift.io/blog/engineering
The skills are useful, thanks for linking them! They'll be useful for my future projects like this. FWIW I've had good luck with using Claude Design first to do mocks.
At the same time, I think there's still the "is this worth doing a hyper-customized version of this software, if I'm also then responsible for fixing the bugs?". But I think increasingly as we improve our agentic workflows and make them more self-contained loops driving the result to completion, this becomes kind of a non-issue.
In general, I do think LLMs are bringing about a new age of hyper-customization, which I welcome.
Accepting contributions is not required to be open source.
SQLite doesn’t accept contributions from random people either [0] (though you could argue being public domain isn’t being open source).
Anyway, this is great, I was waiting for this to take the language for a spin! Congrats to the Mojo team!
[0]: https://simonwillison.net/2025/Dec/29/copyright-release/
I’m using that setup and have no issues with it, for exactly the use-case you mentioned.
Side note, I moved to Fastmail a couple years ago, and so far I’ve been very happy with it! The Gmail migrator works great, too.
We're a VC-funded startup (recently raised $51M Series C) building an infrastructure orchestrator and collaborative management platform for Infrastructure-as-Code – from OpenTofu, Terraform, Terragrunt, CloudFormation, Pulumi, Kubernetes, to Ansible.
On the backend we're using 100% Go with AWS primitives. We're looking for backend developers who like doing DevOps'y stuff sometimes (because in a way it's the spirit of our company), or have experience with the cloud native ecosystem. Ideally you'd have experience working with an IaC tool, i.e. Terraform, Pulumi, Ansible, CloudFormation, Kubernetes, or SaltStack.
Overall we have a deeply technical product, trying to build something customers love to use, and have a lot of happy and satisfied customers. We promise interesting work, the ability to open source parts of the project which don't give us a business advantage, as well as healthy working hours.
If that sounds like fun to you, please apply at https://careers.spacelift.io/jobs/3006934-software-engineer-...
You can find out more about the product we're building at https://spacelift.io and also see our engineering blog for a few technical blog posts of ours: https://spacelift.io/blog/engineering
While for the other side where the sovereignty is not an important factor, it's product quality that matters.
You can absolutely make a European startup that sells B2B SaaS, successfully, it just has to be better than the competition, and being European will not be enough.
We're a VC-funded startup (recently raised $51M Series C) building an infrastructure orchestrator and collaborative management platform for Infrastructure-as-Code – from OpenTofu, Terraform, Terragrunt, CloudFormation, Pulumi, Kubernetes, to Ansible.
On the backend we're using 100% Go with AWS primitives. We're looking for backend developers who like doing DevOps'y stuff sometimes (because in a way it's the spirit of our company), or have experience with the cloud native ecosystem. Ideally you'd have experience working with an IaC tool, i.e. Terraform, Pulumi, Ansible, CloudFormation, Kubernetes, or SaltStack.
Overall we have a deeply technical product, trying to build something customers love to use, and have a lot of happy and satisfied customers. We promise interesting work, the ability to open source parts of the project which don't give us a business advantage, as well as healthy working hours.
If that sounds like fun to you, please apply at https://careers.spacelift.io/jobs/3006934-software-engineer-...
You can find out more about the product we're building at https://spacelift.io and also see our engineering blog for a few technical blog posts of ours: https://spacelift.io/blog/engineering
Based on the headline I thought it’s the built-in apps.
Not affiliated with the bench in any way, but I think it surfaces important differences between the behavior of the models from different labs.
TLDR: The benchmark is measuring pushback in response to nonsensical requests and questions, as opposed to going with it and hallucinating a nonsensical answer.
[0]: https://petergpt.github.io/bullshit-benchmark/viewer/index.v...
We’re doing well, are steadily growing, and have been actively hiring backend engineers ever since!
Is there any specific concern you have?
We're a VC-funded startup (recently raised $51M Series C) building an infrastructure orchestrator and collaborative management platform for Infrastructure-as-Code – from OpenTofu, Terraform, Terragrunt, CloudFormation, Pulumi, Kubernetes, to Ansible.
On the backend we're using 100% Go with AWS primitives. We're looking for backend developers who like doing DevOps'y stuff sometimes (because in a way it's the spirit of our company), or have experience with the cloud native ecosystem. Ideally you'd have experience working with an IaC tool, i.e. Terraform, Pulumi, Ansible, CloudFormation, Kubernetes, or SaltStack.
Overall we have a deeply technical product, trying to build something customers love to use, and have a lot of happy and satisfied customers. We promise interesting work, the ability to open source parts of the project which don't give us a business advantage, as well as healthy working hours.
If that sounds like fun to you, please apply at https://careers.spacelift.io/jobs/3006934-software-engineer-...
You can find out more about the product we're building at https://spacelift.io and also see our engineering blog for a few technical blog posts of ours: https://spacelift.io/blog/engineering
> Nothing beats an organic, pasture-raised, hand-written spec.
Hah, I strongly empathize with the wording. I’ve been starting my design docs for fellow humans with “100% hand-written, organic content”, I might steal a part of yours.
Overall, cool idea. I don’t see myself using your SaaS, but the approach of tagging the requirements and constraints to make them easier to find sounds good.
One project you didn’t mention which I think is also, I think, a cool perspective on this is codespeak.dev , but I haven’t given it a go yet.
All in all, I feel like maintaining specs, and having agents translate spec diffs into code diffs is a promising area for the future. Good thing I enjoy writing!
email: jakub.wit.martin at gmail dot com
work email: kubam at spacelift dot io
linkedin: https://www.linkedin.com/in/jakubmartin
github: https://github.com/cube2222
Author of OctoSQL: https://github.com/cube2222/octosql