boltzmann-brain

8086K, actually. I still run one inside one of my PCs!

Helped a friend make a difficult career decision (cozy job vs something hard and new + moving to a new city) that ultimately ended up with him working on the project. Glad that happened. I love to see people grow.

Main tech skills:

AI/ML: LLMs, RAGs, predictive models, machine vision; MLops (K8s, Airflow, Kubeflow, Flyte, Seldon, KEDA, ELK, Kibana), end-to-end systems (algorithms, data pipelines, training, inference, deployment); Vector DBs (Qdrant, Chroma); data lakes; performance- and cost-driven implementations (C++/Rust).

Backend / systems (languages): Rust, Python, Go, Zig, C++, C, Haskell, Scala, Typescript, Node.js, Next;

Infra / DevOps: NixOS/Nix, AWS, Terraform, Docker, Ansible; CI/CD, Linux internals, observability, reliability engineering.

Fintech / crypto: Launched Tezos and other blockchains; smart-contract audits; regulated, security-critical environments; built production systems for trad banks.

Security: Cryptography, threat modeling, audits, reverse engineering.

Leadership: Staff+ IC → CTO; led teams 2–30; hiring, mentoring, technical strategy, raising VC.

    Location: EU, overlap with PST
    Remote: Yes
    Relocation: No
    Technologies: Rust, C++, Python, Go, Zig, Haskell, TypeScript, Nix, K8s, Terraform
    Email: damianjobsites+hn@gmail.com
    CV: on request

Senior engineer / tech lead (20+ YOE). Former IC → EM → Director → CTO. Multiple exits. Hands-on, or owning the whole technical org.

Highlights: - Designed and shipped a commercial LLM end-to-end (algorithms → training → MLops) - Launched and audited major blockchain systems (e.g. Tezos) - Shipped production systems for Oracle, Shell, Time Warner, BoA, Sparkasse, Saatchi & Saatchi, Digitas - Built and scaled a software NGO (500k+ supporters, 1k+ volunteers)

Strengths: - Turning ambiguous problems into shipped systems - MVPs that don’t need rewriting - ML, LLMs, RAGs, vector DBs - Rigorous code and infosec audits for mission-critical infra - 10x–1000x performance wins on legacy systems - FP, Compilers, DSLs, distributed systems, security-critical code

Further work: - Contributor: Rust Book, Rust By Example, Python docs, Haskell Communities and Activities Report - Dozens of smart contract audits - Background in cryptography, infosec, formal methods

If you need someone who can own the stack and ship reliably, email me at damianjobsites+hn@gmail.com

That's very deep water to dive into. I suggest something simpler, like an ancient irc client that asks you to sign up, or an archive extractor.

> The "money goes to the repo part" is the problem here, as it incentivizes maintainers to refuse legitimate pull requests.

That's not true. The issue is that the system the comment you're replying to described is escrow. Escrow degenerates in the way that you describe. I explain it a bit more in this comment elsewhere on this post:

https://news.ycombinator.com/item?id=46943416

A straight up non-refundable participation payment does not have this issue, and creates a different set of incentives and a different economy, while there also exist escape hatches for free-of-charge contributions.

> The real problem here is the amount of work necessary to make this viable.

Not necessarily. This article mentions Tezos, which is capable of doing such things on-chain already:

https://news.ycombinator.com/item?id=46938811

> all the annoying KYC/AML that a normie has to get through to use it.

There are always escape hatches. If your code is so great that people will want to pull it, then you don't pay to push. If it's not really that great, then what are we talking about? Maybe it disincentivizes mid code being pushed. So be it.

You can make friends, you can make a name for yourself, you can make a fork that's very successful and upstream will want to pull it in, you can exert social pressure / marketing to get your code merged in. Lots of options that do not involve KYC/AML.

For everyone else, I'd say KYC/AML are a good idea because of the increasing amount of supply chain exploits being pushed out into repos. If pushing by randos is gated by KYC/AML, then there's at least some method of chasing the perps down and taking them to justice.

That's a win-win-win-win situation. Less mid code, less exploits, earnings for maintainers, AI slop blocked. Absolutely amazing.

pay-to-commit has been discussed in the article linked here

https://news.ycombinator.com/item?id=46938811

escrow is a more complex system, and there are multiple possible implementations, but the nice thing is you can skip it and get the same results.

let's assume for a second that the repo owner spends time on PR review, and that time needs to be reimbursed. let's also assume that the person pushing a PR expects some sort of bounty. then as long as the review price is less than bounty price, there's no need for escrow. the pushing party goes out on a limb paying the reviewer to merge their PR, but also expects (rightly or not) to be remunerated for solving the bounty. whether they really did solve it is in the remit of the bounty originator, who might or might not be part of the group controlling the repository. if there's escrow, then the bounty giver probably has to be part of that group. not having escrow allows for crowd funding by interests outside of the repo controlling party.

escrow is only usefully different in a situation when there is no bounty, you want to push code, and then you want to say "ok, here's some money, and here's a PR, either accept the PR and give me money or don't accept it and take my money" as a means of skipping the line or getting a shot at pushing in the first place. however, at that point two things are apparent: 1. you expect the reviewer to do work required to implement your desired changes for free and 2. this might start getting abused, with PRs getting rejected (to gain money) but then modified / refactored versions of this code being pushed via commits or from another user who is the repo owner's puppet (refactoring code is becoming super cheap due to AI). so that degenerates escrow-to-push into a scam.

there are more considerations like that in the article I linked to. I agree that an economy around FOSS pushing would be desirable. it also doesn't preclude free-as-in-money contributions - there are at least two mechanisms that would allow it: 1. you get sponsored by someone who sees your talent (either gives you money to push, or they have push access to that repo and can hand it out free) 2. you create a fork that becomes so good and valuable that upstream pulls from you for free

ultimately becoming a respected developer with free push access to contended repositories should be something that you can monetize to some extent that's purely within your remit, and it would greatly reduce unserious bullshit coming from third parties (especially all those weird hardware developers) and make it easier to be a FOSS dev.

GitHub has never been a good method of clout chasing. in decades of being in this industry, I've seen < 1% of potential employers care about FLOSS contributions, as long as you have some stuff on your GH.

Vouch is a good quick fix, but it has some properties that can lead to collapsed states, discussed in the article linked here: https://news.ycombinator.com/item?id=46938811

An exposition of problems in trust ecosystems, a critique of Vouch, and a suggestion for some fixes.

> Total Depravity: If your code’s correctness depends on keeping complicated interconnected structure in your head, a devastating incident is not a matter of if but when.

> Therefore, delegate these concerns to tooling and a sufficiently powerful compiler, use types to guard against errors, and free yourself to only mentally track the actual important things.

do they allow the following? https://news.ycombinator.com/item?id=46859860

can Granule let me specify the following constraints on a function?

- it will use O(n) space where n is some measure of one of the parameters (instead of n you could have some sort of function of multiple measures of multiple parameters)

- same but time use instead of space use

- same but number of copies

- the size of an output will be the size of an input, or less than it

- the allocated memory after the function runs is less than allocated memory before the function runs

- given the body of a function, and given that all the functions used in the body have well defined complexities, the complexity of the function being defined with them is known or at least has a good upper bound that is provably true

Rust or Haskell. Python is subpar in terms of maintainability especially when it comes to long-running, generational, massive, codebases. Python is also massively worse when it comes to performance. Haskell strikes the perfect balance here, I've worked at companies with massive codebases where maintaining is still a breeze years later. This simply does not happen with any OOP languages, the code always turns into an ingrown hedge with time.

Especially when it comes to long-running projects like what's attempted here, Python, even being a technology from yesteryear, isn't even suited for problems of yesteryear.

With projects like these maintainability is your #1 concern, so referential transparency (greatly reinforced by laziness-by-default) and purity are indispensable and irreplaceable here.

The next concern is adequate performance, and Haskell has that in heaps.

The final concern is the capability to find programmers, and there are heaps of those in Haskell land.

Main tech skills:

AI/ML: LLMs, RAGs, predictive models, machine vision; MLops (K8s, Airflow, Kubeflow, Flyte, Seldon, KEDA, ELK, Kibana), end-to-end systems (algorithms, data pipelines, training, inference, deployment); Vector DBs (Qdrant, Chroma); data lakes; performance- and cost-driven implementations (C++/Rust).

Backend / systems (languages): Rust, Python, Go, Zig, C++, C, Haskell, Scala, Typescript, Node.js, Next;

Infra / DevOps: NixOS/Nix, AWS, Terraform, Docker, Ansible; CI/CD, Linux internals, observability, reliability engineering.

Fintech / crypto: Launched Tezos and other blockchains; smart-contract audits; regulated, security-critical environments; built production systems for trad banks.

Security: Cryptography, threat modeling, audits, reverse engineering.

Leadership: Staff+ IC → CTO; led teams 2–30; hiring, mentoring, technical strategy, raising VC.

    Location: EU, overlap with PST
    Remote: Yes
    Relocation: No
    Technologies: Rust, C++, Python, Go, Zig, Haskell, TypeScript, Nix, K8s, Terraform
    Email: damianjobsites+hn@gmail.com
    CV: on request

Senior engineer / tech lead (20+ YOE). Former IC → EM → Director → CTO. Multiple exits. Hands-on, or owning the whole technical org.

Highlights: - Designed and shipped a commercial LLM end-to-end (algorithms → training → infra) - Launched and audited major blockchain systems (incl. Tezos) - Shipped production systems for Oracle, Shell, Time Warner, BoA, Sparkasse, Saatchi & Saatchi, Digitas - Built and scaled a software NGO (500k+ supporters, 1k+ volunteers)

Strengths: - Turning ambiguous problems into shipped systems - MVPs that don’t need rewriting - ML, LLMs, RAGs, vector DBs - Rigorous code and infosec audits for mission-critical infra - 10x–1000x performance wins on legacy systems - FP, Compilers, DSLs, distributed systems, security-critical code

Credibility: - Contributor: Rust Book, Rust By Example, Python docs, Haskell Communities and Activities Report - Dozens of smart contract audits - Background in cryptography, infosec, formal methods

If you need someone who can own the stack and ship reliably, email me at damianjobsites+hn@gmail.com

Yes - high-performance Haskell code looks similar. There isn't much to be said there - it's a little less clean-looking because FP optimizes for the most useful scenario and trying to do highly advanced stuff like that will be more verbose. This is in contrast to OOP where everything is verbose, and sometimes high-perf stuff that falls into the shape of globals + mutation + goto looks very succinct.

that isn't much of a problem - git repositories can be re-hosted somewhere else. carrying the bug tracker over is another issue entirely.

god, out of all the technologies of yesteryear, why Django?

That's a dramatic but fitting characterization of https://en.wikipedia.org/wiki/Goodhart%27s_law

it's a massive crime that decades into FP, we still don't have a type system that can infer or constrain the amount of copies and allocations a piece of code has. software would be massively better if it did - unnecessary copies and space leaks are some of the most performance-regressing bugs out there and there simply isn't a natural way of unearthing those.

yes

> who have to put up with us

this kind of (self-)deprecation is exactly the kind of thing that makes it impossible to be happy as a technical person in a startup

except "work expands so as to fill the time available for its completion", and therefore, after each of the 9 tasks is completed, there is no time left for the 10th task. so this only works if the disaster happens very early, or if you do almost all of the tasks in parallel. neither is the expected case.

critical reading does not require clairvoyance

oh god, i find the sidebar so intensely annoying. glad i have the Dom Delete addon, i would never manage to read anything otherwise

thinking critically is left as an exercise to the reader.

i disagree with that stance. an open source project is made up of contributions by dozens, maybe thousands of people, and they almost always only contributed to that one specific repository under that one specific person's control due to game theoretical processes that are mostly random, such as first-mover advantage, schelling points, etc. the collective effort of those people usually far outweighs what the controlling person usually contributed to ostensibly earn this sort of privilege. if talking about a FOSS repository, that person cannot be correctly described as "the owner" of that work, as the work is owned by the public, i.e. anyone who is provided access to the code. the person you are describing is merely the current maintainer of the project and the fact that most of the work they are maintaining is not theirs, but comes from the public, and is meant for the public, immediately puts a burden of responsibility on them of acting in a way that is much better than "a project owner have the right to be dismissive about anything regarding their own project" - a mode of operation which, if you pull in all the considerations i presented here, sounds childish. a much better way is to talk about this like you would about an old watch: you are merely maintaining it for future generations. that puts you in a more humble and less combative mindset.

The readers on this website are hopefully less lazy than that

the propensity for fediverse admins to act like tiny dictators is extremely worrying. i haven't seen a good solution to this sort of thing honestly. ultimately it also means that you have to walk on eggshells and force yourself into an impossible shape lest you offend someone's very special interest that you didn't even know you were lightly brushing up against (for example, you say "clanker" and therefore the owner of some instance immediately and without asking thinks you are against cyborgs, and they identify as a cyborg, therefore you are a bigot, and you get banned without warning and all your friendships are gone - didn't happen to me, but i've seen it happen to someone else). one of the worst things about this is that you can't have a really strong disagreement with people who are popular on some instance because social inner circles form very easily on tiny instances, and all of them are tiny, especially compared to non-federated, centralized networks where brushing up against inner circles that have connections to admins is much much less likely.