Location: Portugal
Remote: Yes
Willing to relocate: No
Technologies: Rails, Django, Postgres, React, Node, Next.js, Go, Postgres, Redis, KDB+
Résumé/CV: https://0x1.pt/Vitor_Sousa_Pereira_CV.pdf
Email: vmsousapereira@gmail.com
I was founding and lead engineer at a London-based startup that got sold last year. Since then, I've been enjoying a career break, trading some options and working on some projects.
I didn't know I was part of a trend, that's pretty cool. I've been buying originals related to the Portuguese Estado Novo and Carnation Revolution for some years. A ton of ad-hoc, clearly political, publishers spawned right after the revolution and I've been thinking of digitizing some of the stuff I have for historical purposes.
With the kind of press it’s getting, I bet this model will outsell all others made in the last 10y. I don’t remember the last time a Ferrari was on the news.
For people who buy a Ferrari the price is not part of the equation at all.
Also Ferrari’s whole game is demand and supply manipulation - there are always more people who want a Ferrari than can actually buy one. These will all sell out whatever happens.
Yeah, how many agents can you people even run at once and how much does it cost you? In company we used the monthly token quota and nowadays it's basically unusable with claude opus 4.6 on high reasoning. You can basically burn through 100% usage through a single day. How does it even scale for you with N agents and which magical plans or models do you use, where tools like this are even viable?
for clarification we're less of a agent swarm tool, and more of a launch a bunch of independent agents in isolated environments and have some nice UX to manage them too. I also havent had as much luck with agent swarms or ralph loops, but i'm sure the laps will improve them with time
Node's the stable solution and will be with us forever. You can now use TypeScript with it and, soon enough, you'll be able to build your app to a single executable -- including native deps.
Bun's chaotic but, nonetheless, it's _fast_ and it's taking an interesting approach by including everything in the stdlib. Plus, bought by Anthropic.
Deno had an awesome story with the sandbox and ease of import for third-party dependencies. Sandboxes feel pretty commoditized now and I'm not sure the import mechanism ended up being that much nicer than a `npm add`.
That's a yes and no. Venture funded companies like Anthropic have a history of low follow through with peripheral projects (like Bun is for them). Of course they do - their responsibility is ultimately primarily to their investors - not to Bun. So the risk now is that Anthropic will can Bun whenever they just lose interest or feel it's just a drain that's not contributing directly to their bottom line.
Node.js itself did have trouble finding a corporate home that was interested in providing good support for the project, and that's how we got the oi.js fork of Node, which luckily led to Node being transitioned to a foundation and the projects merged. This whole history is what made me so surprised that Ryan of all people would attempt another js runtime (Deno) project as a corporate project.
And it's the reason I'm staying away from both Bun and Node. I can't afford platform risk like this. I need my startup to be built on a project that has a more reliable future trajectory, which is what you get with a proper open source project (emphasis on project) that you get with Node. Node is stable and still getting features, but most importantly it's not going away.
I see how this might seem like it would make Bun important to Anthropic, but there are just so many examples of companies losing interest in the technology that their product "runs on". It's just infrastructure to them. To the C-suite, infrastructure is fungible.
Running out of money is never the issue with a big company buying an open source project. There are countless examples of projects dying or changing significantly for the worse after acquisition.
Also “no human wrote any of this code” is not my personal benchmark for a reliable dependency.
> It means they're a whole lot less likely to run out of money, which makes them a safer bet as a dependency.
I don't think this logically follows. That is, yes being acquired makes one less likely to run out of money, but doesn't necessarily make something safer as a dependency.
Plenty of open source projects have little to no funding and continue on for years with no problems. But being acquired suddenly creates a requirement of return-on-investment. A corporation will happily shut the whole thing down if and when it's decided that they're just not gaining enough value from it.
(There's also the general fact that, a corporate-acquired project is going to first and forement serve the needs of the corporation vs. the community at large - if your use case or edge case doesn't align with the needs of Anthropic then you should probably not hold your breath waiting for the Bun project to address it.)
For those who care about their dependencies being "safe bets", Bun should already be out of the question after the recent "vibe code the entire thing into a different language in a week with zero human intervention" fiasco.
Afaik there is no proof Anthropic is profitable. This, and uv buyout by OpenAI only adds a risk to supply chains. In few years these companies can be overrun by open source models or startups delivering new hardware/software breakthrough in LLM. It is not like uv and bun are acquired by IBMs or Alphabets of today.
Wasn't it announced that Anthropic is having their first profitable quarter right now in Q2? From what I've personally seen it's all driven by enterprise adoption.
Open source/foreign models are already way cheaper and will work just fine for most use cases but a lot of businesses are already pretty locked in to Claude, and with enterprise costing $240 a year at a 20 seat minimum it's a pretty big investment to make and won't be worth migrating unless the gains are significant.
No, the same thing always happens. The community latches onto a new project where all the effort is spent chasing previous gains, then they get bought out, and over time the same pattern appears.
At this point our industry would benefit from public investment in open source in the form of grants rather than relying on corporate benefactors to not rat fuck the commons.
I agree philosophically, but the JavaScript ecosystem has never been languishing for lack of options. If anything, excessive fragmentation is a real concern.
Some companies do this and pay the candidate for their time, regardless of outcome. I don't think there's much to comment there. Some don't pay the candidate. In that case, it's just a predatory practice to take advantage of the tough job market.
Just my personal take on this, but I’d happily perform real work for free instead of sitting for leetcodes and behavioral questions. I struggle with those formats a lot but have no problems shipping in a realistic problem domain.
That tradeoff makes enough economic sense to me personally, but to each their own.
I do agree that companies flush with profit should be able to offer a stipend though, and unwillingness to do so is a signal I use to evaluate them.
Everyone prefers real problems. It's something you already know how to do instead of something you explicitly have to train for.
It doesn't change the fact that the real work could be an hour's exercise or longer remunerated work. This isn't an either/or scenario like you put it. Plus, for a fact, companies will happily have you doing both the leetcode and the take-home test.
I would never perform work for free. What if my work has a hidden oopsie that ends up causing problems later? What if the code review is lax, and a bug ends up hurting someone? Unlikely scenarios, but things I’d be concerned about.
From what I've seen it _seems_ the language's creator is not interested in corporate sponsorship. It's been some time since I was interested in Nim, so I don't have any direct references to this claim. A web search would probably provide several examples. It was one of the main reasons why I decided to focus on other languages.
It sits in the sweet spot for projects like nitter--which is not the kind of work that's attracting investment right now, but that's due to markets being a clumsy tool for deciding what should be done and nothing to do with Nim's merits.
Location: Portugal
Remote: Yes
Willing to relocate: No
Technologies: Rails, Django, Postgres, React, Node, Next.js, Go, Postgres, Redis, KDB+
Résumé/CV: https://0x1.pt/Vitor_Sousa_Pereira_CV.pdf
Email: vmsousapereira@gmail.com
I was founding and lead engineer at a London-based startup that was sold back in December. Since then, I've been enjoying a career break and also working on projects of mine. Latest of which is https://hanlec.com and now an options backtesting platform that I'm still working on.
Wouldn't this kind of architecture yield a slower compiler, regardless of output quality? Conceptually, trying to implement the least-amount of passes with each doing as much work as possible would make more sense to me.
There is nothing stopping you from building an old-fashioned single-pass compiler, if compile time is your only concern. The code it generates just wouldn't be very good.
This highly depends on the language and your skill as a compiler writer. You can write a single pass assembler that generates great code but you have to of course write the low level code yourself (including manual register assignment). To do decent automatic register assignment, I agree you need at least two passes, but not 10 or more.
> There is nothing stopping you from building an old-fashioned single-pass compiler, if compile time is your only concern. The code it generates just wouldn't be very good.
Define "very good".
The very simplest optimizations get you almost all the benefit. Proebsting's Law applies: Compiler Advances Double Computing Power Every 18 Years
reply