_acco

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?

My best guess for the sparse icons in older MacOS versions: icons only for frequently-used menu items.

I disagree. I started with Elixir and its OTP resources are really good. Books like Elixir in Action do a great job.

I read Programming Erlang later, but it was just for fun, and I knew most things already at that point.

False, payroll taxes are split.

And Texas is famous for its property taxes.

You think they don’t pay payroll tax, sales tax, or property tax?

Operating a business means consuming and producing things, which involves paying taxes.

Clickbait title.

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 consider myself expert-level at Elixir and did not learn Erlang first. Couldn't write a single line of Erlang today unaided if I tried.

I picked up Joe's Erlang book years after out of pure joy/curiosity.

Especially with LLMs, totally unnecessary.

It doesn't matter as much as you think. I believe this is in part due to how assertive most Elixir code tends to be. [1] These assertions not only aid the LSP and can cause compiler warnings/errors, they also help LLMs just like types do.

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

[2] https://hexdocs.pm/elixir/main/changelog.html

This is a good way of framing that we don't understand human creativity. And that we can't hope to build it until we do.

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.

Your unique advantage is you know Vitess super well. Your unique disadvantage is you know Vitess super well! Second system syndrome is real. Using as much Vitess as possible could help you guard against it.

Excited to follow your progress :)

This is so cool. A key benefit is that it's not embedding the C Lua runtime and compiler, but rather implements Lua in the host language (Elixir/Erlang).

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!

Why do we use hotkeys and snippets?

There is a lot of tedium in software development and these tools help alleviate it.

Sequin | Platform Engineer | San Francisco | ONSITE 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/

Sequin engineer here. We'll publish our benchmark repo soon! Indeed, we're still doing a lot of fiddling with Debezium ourselves to make sure we cover different configurations, deployments, etc.

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 :) )

Sequin | Platform Engineer | San Francisco | ONSITE

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/

AFAIK, the reason for these changes is basically "prevent AWS from eating our business". Is that right?

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?

Very fun – I wasn't aware, thank you!

Aye, thanks! That's very helpful to hear. I just cut back our use of the acronym a ton:

https://github.com/sequinstream/sequin/commit/28bfba603da6d2...

We just applied this framework to the Sequin [1] docs two weeks ago. It has felt so nice to have a framework. I think our docs flow really well now, and it's been easier for us to add and maintain docs because we know where to put things.

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 :)

Aye, good catch! Honest mistake. Fixed.

That 2011 snapshot actually makes the opposite point: the WordPress logo is prominently displayed next to the "WP Engine" title on the screenshot!

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")

Stoked you watched, thanks. (Sorry the example isn't the greatest/lacks context. The first video was better, but the mic gain was too high.)

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.

Context is the most challenging bit. FWIW, the codebases I'm working on are still small enough to where I rarely need to include more than 12 files into context. And I find as I make the context bigger beyond that, results degrade significantly.

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:

https://www.loom.com/share/20d967be827141578c64074735eb84a8

I don't. But that's probably because I'm very opinionated about the implementation details, so I'm scrutinizing and tweaking its output a lot.

I said leveraging, not hawking!

Hmm, I've definitely always used paid copilot models.

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.

As I mentioned in a sibling comment, I now "pair program" all day. Instead of being the driver and navigator all day, I can mostly sit "one layer up" in the navigator seat.

It helps me stay in flow by keeping me one layer up.

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.

AI (specifically Claude Sonnet via Cursor) has completely transformed my workflow. It's changed my job description as a programmer. (And I've been doing this for 13y – no greenhorn!)

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.

You can’t participate in performance arts remotely.

Not to say anything about networking, which is critical for most arts.