pmbanugo

It's not a problem specific to Rust. It's more around async/await as a concurrency primitive. Same can be said about Node.js or many other languages

I really love ZeroMQ. Wish more people will use it.

After reading Posthog's blog about their recent issue and fix regarding their use of Tokio + Rayon, I decided to write about it.

Unrelated to Rust, but a common problem I see with async/await as a primitive for concurrency.

I've been thinking about concurrency and distributed messaging system for a while now. I started tinkering with various aspects of ZeroMQ, then explored designs and protype-implementation of a QUIC-based message protocol (like an alternative to NATS and similar). Hit some roadblocks and went back into thinking about concurrency and async I/O.

Then after a few pivots I landed on a good design for a framework which embodies what I'd like to see about programming concurrent systems without the gotchas of today's primisitives (e.g. callbacks/promise hell).

So I recently open sourced it (https://github.com/pmbanugo/tina). It's a high-throughput concurrency framework that bridges the Erlang-style concurrency with native performance (no VM, no GC).

One other area I'm interested in is formal method design using TLA (by Lamport). But I'm still scratching the surface on that one.

Sadly the life of many things frontend.

I don't see anything fancy here that Google doesn't do with their Gemini products, and even better

quite interesting. So SQL patterns can be optimised differently in SQLite

Would we have a better or evolved markdown?

marketing is how ideas spread. And ideas that spread are those that win.

That's why AI-sloppy software would go viral and make loads of money while properly engineered ones die off.

When people need knowledge, they know where to find it. They don't need marketing for that.

Engineering You by @mjpt777 is one of my favourite things to learn/watch in the past week.

It talks about what makes a software engineer and how to get better at it. You'd have thought Mathematics and Algos/Data-Structure aren't important.

have they reverted to microservices?

this performance aspects is interesting. So time to try C# again. I;m learning Zig for some of those reasons, but also because the language has a small scope and the language features will be smaller

I wrote my first queue this week, and started learning DSA this week as well. I use to ignore those topics, but I think the path I seek would benefit from that knowledge.

Thanks. web dev or game dev are still developers. I don't subscribe to the "real developer" mindset, except if they're vibe coders :)

After years in web development, I’m hitting the reset button. For the next 12 months, I'm going all-in on learning Zig and systems programming—in public. I'm anxious, excited, and ready to tackle something hard.

Zig is only a means to an end. I recently shared Phil Eaton's post, and it helped me reach this decision after a long time having this nagging feeling.

LOL!

This is cool, keep it up!

I like the Erlang VM concepts and I enjoy attending their meetups

+1000

I enjoyed reading this. It could be because I'm thinking of doing more of system/network programming (and learning Zig). I've spent the last 6 years in the JavaScript land and bored of yet-another-bundling or SPA-like pattern.

So there's hope that with consistency and patience, one could build expertise in a totally different area

tell me you're not a Node.js developer :)

Hey thanks for posting here!

I built Demitter to solve a problem I kept thinking about recently: how to easily share events between Node.js processes without the complexity of setting up Redis, RabbitMQ, or other heavyweight message brokers? It uses ZeroMQ for messaging and MessagePack for serialization, ensuring high performance even at high event frequencies.

What it does:

- Takes the familiar `emitter.on()` and `emitter.emit()` API you may already know in Node.js - Makes it work seamlessly across multiple processes/machines - Zero configuration required: just `npm install demitter` and go

Don't take my word for it, see it in action:

I created a live auction demo where multiple bidders run in separate terminal windows, all bidding in real-time on the same auctions. Watch it in action: https://www.youtube.com/watch?v=LqQShQ9-dsk – it's pretty satisfying to see ~7 processes staying perfectly synchronized in real-time.

Where I you might use it:

- Worker processes needed coordination without complexity - You want to scale Socket.IO or WebSocket servers without heavy message brokers - any other need for pub/sub across Node.js processes.

I built this because I wanted a lightweight solution that didn't compromise on the familiar Node.js event API. Existing solutions felt too heavy for simple pub/sub, and I wanted to keep the Node.js event API developers already know.

I'd love to hear your thoughts on this approach. Is it something you would find useful? What other use cases do you think it could solve for you?

I'm in EU and it's very late here, so I'll catch up on comments tomorrow.

Maintaining bad AI code would be committing or shipping bad AI code in the first place

Is ocaml worth learning today?

I mostly work with JS and last month picked up learning Zig and building things with it. Zig ecosystem is still early but fun to play around, plus the community folks are helpful with answering my noob questions

A sort of rant about code literacy vs vibe coding and generative AI

I'd try it just for the LMDB mixing

I haven’t tried Claude 4. Maybe I’d give it a spin to see if it can improve my design document

Looks like an elevated vibe coding method for UI development. Does this work for non-web/UI development?

That’s what the recent Copilot feature on GitHub can do. You assign it tasks and it comes back with a PR. You could also assign it to review a PR.

re-reading the title makes me feel like I used a wrong title.

Could be a good idea for a non-profit like you said. I know someone who’s exploring something similar but for disabled folks who aren’t tech-savvy (for-profit)