Hacker News new | past | comments | ask | show | jobs | submit | williamstein's comments login

Synadia might not be very good at encouraging community involvement in development and has perhaps not made an effort. I've watched most of the videos they've posted on youtube, and they seem very proud of keeping total control of the project. I don't think there's anything fundamental to the NATS software that discourages community involvement; in fact, their code is extremely well written and easy to read in a developer friendly language (Go). However, there is something about how the project is actively run that seems to discourage community involvement. I've coincidentally been publicly documenting [1] my own surprising frustrations with trying to get involved during the last few months. Many other open source projects I'm involved with, e.g., Jupyter, SageMath, Cython, have much more welcoming governance structures, with regular welcoming developer meetings open to everybody, etc.

All that said, NATS is Apache licensed software, and any company is legally allowed to create and maintain a closed-source fork based on this. CNCF claims the trademark "NATS" and the domain name nats.io.

I have often wondered if the name "NATS" is an overly confusing name. People often think it means "Network Address Translation". I suspect changing the name to something else that involved PubSub or Queue or DB would be a net win in the longrun.

[1] https://github.com/williamstein/nats-bugs


UPDATE: Synadia has agreed with the CNCF requirements. See the new joint statement: https://www.cncf.io/announcements/2025/05/01/cncf-and-synadi...

For some applications especially those that benefit from cpu-bound parallelism, it is possible to write much faster code with Go than Node.js, e.g., consider the recent port of the Typescript compiler from Javascript to Go:

- https://news.ycombinator.com/item?id=43332830


I think 9rx agrees with you. Node.js shines as a web server. It can be made fast at CPU-bound tasks as well, but you wouldn't be writing idiomatic JS/TS.

The recent tsc port from TS to Go is a good example of that. The TypeScript code in the compiler relied a lot on polymorphism, which made it really hard for the JIT to do a good job.

The Go port enabled them to 'rewrite' it keeping the logic more-or-less 1:1 and land a good performance increase. IMO it was a good decision, specially the language choice, and much saner than what a JIT-friendly TS compiler would be.


Context:

- https://news.ycombinator.com/item?id=43829008

- https://github.com/cncf/toc/issues/1632

- https://github.com/nats-io/nats-server/issues/6832

I also built a lot on NATS Jetstream, and I'm questioning my decision in light of the threatened license change.


Why? Have you actually ready Synadia's comments where they made it clear that they always intended to maintain the Apache 2 Version by contributing the stuff they build back to the main repo? It just won't be as fast, so they can make some money first which will fund them giving it away.

You said "I also built a lot" Are you making money off those projects or get paid for your services for that use?


FWIW I also build a lot on NATS for work, and we pay Synadia for consulting. We would have taken our business elsewhere due to the license change has that happened.

I evaluated a range of options and selected NATS for a project in Jan 2025, then spent every waking moment developing and launching this project over the last four months. Absolutely central to my choice of NATS was that it is a CNCF project. You see, I was badly burned a few years ago but what happened with RethinkDB, which I used for a similar purpose!

I read substantial chunks of the NATS source code and contributed many small PR’s and suggestions back. Sometimes the devs were very welcoming and sometimes not. In fact, a few weeks ago I started this repo to document some contributions frustrations: https://github.com/williamstein/nats-bugs

Anyway this rug pull is extremely disappointing to me. It is especially sad because NATS is excellent technology, and no matter what their just shot themselves in the foot, and I had really really had hope for them to grow a lot in the next few years.



Fortunately, this has significantly improved since dedup was rewritten as part of the new ZFS 2.3 release. Search for zfs “fast dedup”.


And even dedup was finally rewritten to be significantly more memory efficient, as of the new 2.3 release of ZFS: https://github.com/openzfs/zfs/discussions/15896


Totally. And yet rigorous proof is very difficult. Having done some mathematics involving nontrivial proofs, I respect even more how difficult rigor is.


Ah, I absolutely don't verify code in the mathematical sense of the word. More like utilize strong static typing (or hints / linters in weaker typed languages) and write a lot of tests.

Nothing is truly 100% safe or free of bugs. What I meant with my comment up-thread was that I have enough experience to have a fairly quick and critical eye of code, and that has saved my skin many times.


Not open source.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: