So cool. Would love to hear more - What app do you use? How often do you clear your inbox and how long does it take?
663 karma · joined April 8, 2017
web: acco.io email: anthony[@]sequinstream.com
I read Programming Erlang later, but it was just for fun, and I knew most things already at that point.
And Texas is famous for its property taxes.
Operating a business means consuming and producing things, which involves paying taxes.
First, this is narrowly about federal income tax. SpaceX presumably pays plenty of other taxes.
Second, using the projected profits in the article, SpaceX will have exhausted its NOL pool by the end of this year, and so will pay billions in federal income tax next year.
But more important: the whole point of these tax cuts and programs is to let businesses use losses today so they can create value — and tax revenue — tomorrow. Of course, if you take a snapshot after part 1 but before part 2, it will always look like “X gets Y from government and gives nothing back”.
I picked up Joe's Erlang book years after out of pure joy/curiosity.
Especially with LLMs, totally unnecessary.
Still, every release now contains new type system features. Next up is full type inference. [2] After that will be typed structs.
[1] José Valim giving his balanced view on type systems: https://www.youtube.com/watch?v=giYbq4HmfGA
i.e. AGI is a philosophical problem, not a scaling problem.
Though we understand them little, we know the default mode network and sleep play key roles. That is likely because they aid some universal property of AGI. Concepts we don't understand like motivation, curiosity, and qualia are likely part of the picture too. Evolution is far too efficient for these to be mere side effects.
(And of course LLMs have none of these properties.)
When a human solves a problem, their search space is not random - just like a chess grandmaster's search space of moves is not random.
How our brains are so efficient when problem solving while also able to generate novelty is a mystery.
Excited to follow your progress :)
When sandboxing user code in another runtime, you need to serialize the data to and from that runtime. That comes with a performance penalty.
So, for example, if you sandbox code in WASM, you need to pick a transport data format, like JSON. You need to serialize Elixir data structures into JSON, send it to WASM, and then deserialize the result. For a high-performance data pipeline, this adds up!
But if your sandbox is in the host language, no serialization/de-serialization is required. You can execute the sandboxed language in microseconds.
I wrote more about this here: https://blog.sequinstream.com/why-we-built-mini-elixir/
Wish this library existed just a couple months ago!
There is a lot of tedium in software development and these tools help alleviate it.
We're making CDC easy enough for weekend projects yet robust enough for Fortune 500 companies.
Sequin is open source/MIT (https://github.com/sequinstream/sequin). We're backed by Kleiner Perkins and Craft Ventures.
Tech Stack: Elixir/Phoenix, LiveView + Svelte, Postgres
What makes this role exciting:
- Join an early-stage open source project with significant technical influence
- Build a tool you would use for a user you understand
- Work deeply with Postgres
- Solve novel distributed systems challenges (not building CRUD apps)
- Work with Elixir/Phoenix and OTP primitives in production
- High-energy environment focused on rapid iteration and customer impact–we ship a lot, and fast!
We're based in San Francisco, where we have an office. Learn more: https://sequin.notion.site/
The main thing we want to communicate is that we're able to keep up with workloads Debezium can handle.
(And, re: RabbitMQ, I wouldn't write off a platform based on a single application built on that platform :) )
We're building the world's fastest change data capture (CDC) platform for Postgres. CDC is a proven pattern that enables real-time use cases like triggering side effects, fanning out events, caching at the edge, and audit logging - but existing solutions are notoriously difficult to set up and maintain.
We're making CDC easy enough for weekend projects yet robust enough for Fortune 500 companies.
Sequin is open source/MIT (https://github.com/sequinstream/sequin). We're backed by Kleiner Perkins and Craft Ventures.
Tech Stack: Elixir/Phoenix, LiveView + Svelte, Postgres
What makes this role exciting:
- Join an early-stage open source project with significant technical influence
- Build a tool you would use for a user you understand
- Work deeply with Postgres
- Solve novel distributed systems challenges (not building CRUD apps)
- Work with Elixir/Phoenix and OTP primitives in production
- High-energy environment focused on rapid iteration and customer impact–we ship a lot, and fast!
We're based in San Francisco, where we have an office. Learn more: https://sequin.notion.site/
If so, are these trends harmful to open source? Are we not choosing between:
1. A world where all revenue in OSS infrastructure ultimately flows to a few big platform companies.
2. A world where these carve-outs are commonplace.
Meta's carve-out with Llama is so interesting because it practically calls the big companies out by name. Should there be a similar standard license for open source infrastructure?
https://github.com/sequinstream/sequin/commit/28bfba603da6d2...
The slightly ironic part is that the Diataxis docs themselves are a bit obtuse. It's a little verbose. So it took a couple passes for it all to click.
The analogy I gave my team that was helpful for everyone's understanding:
Imagine you're shopping for a piece of cooking equipment, like a pressure cooker.
The first thing you're going to look at is the "quickstart" (tutorial) – how does this thing work generally? You just want to see it go from A to B.
Then, you're going to wonder how to use it to cook a particular dish you like. That's a how-to.
If you're really curious about anything you've seen so far, then you'll flip to the reference to read more about it. For example, you might check the exact minutes needed for different types of beans.
And finally, when you're really invested in pressure cooking and want to understand the science behind it - why pressure affects cooking times, how the safety mechanisms work, etc. - that's when you'll read the explanatory content.
Comically, our docs were completely backwards: we lead with explanation ("How Sequin Works"). I think that's the natural impulse of an engineer: let me tell you how this thing works and why we built it this way so you can develop a mental model. Then you'll surely get it, right?
While that may be technically accurate, a person doesn't have the time or patience for that. You need to ramp them into your world. The quickstart -> how-to -> reference flow is a great way to do that. Then if you really have their attention, you can galvanize them about your approach with explanatory material.
[1] https://sequinstream.com/docs
PS: If you have any feedback on our docs, lmk :)
It does look like they fixed just a few months later, though: https://web.archive.org/web/20111001085943/http://wpengine.c...
(How fun to see the selling point "Digg-Proof Scalability")
You summed up the workflow accurately. Except, I read your first paragraph in a positive light, while I imagine you meant it to be negative.
Note the feedback loop you described is the same one as me delegating requirements to someone else (i.e. s/LLM/jr eng). And then reading/editing their PR. Except the feedback loop is, obviously, much tighter.
I've written a lot of tests, I think this would have taken 3-4x longer to do by hand. Surely an hour?
But even if all things were roughly equal, I like being in the navigator seat vs the driver seat. Editor vs writer. It helps me keep the big picture in mind, focused on requirements and architecture, not line-wise implementation details.
So I don't know how this would go in a much larger codebase.
What floored him was simply how much of my programming I was doing with an LLM / how little I write line-by-line (vs edit line-by-line).
If you're really curious, I recorded some work for a friend. The first video has terrible audio, unfortunately. This second one I think gives a very realistic demonstration – you'll see the model struggle a bit at the beginning:
Perhaps it's my language of choice (Elixir)? Claude absolutely nails it, rarely gives me code with compilation errors, seems to know and leverage the standard library very well, idiomatic. Not the same with GPTs.
In pair programming, it's ideal to have a driver (hands on keyboard) and a navigator (planning, direction).
Claude can act as the driver most of the time so I can stay at the navigator level.
This is so helpful, as it's easy as programmers to get sucked into implementation details or low-level minutiae that's just not important.
This wasn't the case with GPT-4/o. This capability is very new.
When I spoke to a colleague at Microsoft about these changes, they were floored. Microsoft has made themselves synonymous with AI, yet their company is barely even leveraging it. The big cos have put in the biggest investments, but also will be the slowest to change their processes and workflows to realize the shift.
Feels like one of those "future is here, not evenly distributed yet" moments. When a tool like Sonnet is released, it's not like big tech cos are going to transform over night. There's a massive capability overhang that will take some time to work itself through these (now) slow-moving companies.
I assume it was the same with the internet/dot-com crash.
Not to say anything about networking, which is critical for most arts.