Starting from the upcoming 0.5 release of Rama (~ end of September '26), Rama's CLI `serve proxy` command will have a Man-In-The-Middle (MITM) mode `--mitm` that will serve a (protected) web GUI to monitor and engage with the network flowing through the proxy.
Happy to also anwer any questions here regarding rama the network framework, or our CLI tool built with it.
Who's right though? The article seems to go directly against what parent said above?
> In Java, there’s a similarly looking thread interruption mechanism. Critically, it doesn’t support interrupting syscalls: IOException and InterruptedException are both checked and unrelated, meaning that IOing functions are not interruptible
One says IOing functions are not interruptible, other says "You can interrupt a blocking IO operation" :)
The article seems to talk about how `Thread.interrupt` works with synchronous IO, rather than the async IO machinery of `java.nio`. So I'd say the article is inaccurate or at least incomplete.
Info for those who do not know Rama yet: it is a modular rust framework to build network services of any kind (client, server or proxies). For projects where you need to combine multiple protocols, be in control of the stack, build advanced stacks or any kind of proxy, rama is probably for you. And if not, do reach out to us.
Earlier this week we released Rama 0.4, and with it we are bringing system configured proxy support to clients (rama-net), this includes PAC support (rama-pac) driven by Javascript within a WASM runtime (rama-js). It also expands our gRPC support and adds support for ttRPC, a lightweight alternative to gRPC running directly on top of TCP.
Read more in the blog post and discover also the other new features and improvements that Rama brings in this new release, that is 0.4.
As always we are very much open to feedback on this Release, rama itself or how it is presented. It's a project 6 in the making, with everything written for production purposes since day 0. Feedback is always greatly appreciated especially if it allows us to improve Rama. Contributions welcome of course as well.
That is a question I can answer in many ways. But the prime answer is that it's a weird question to ask.
When you mention tower you might mean two things:
1. the `Service` and `Layer` concept. That is in the end just a "tool" to provide composition. Just like you also use records (`structs`), procedures (functions) etc... We also lean on that concept. And also note that Tower did not invent that concept either. So in that sense Rama is just another child down the lane of this lineage.
2. The tower ecosystem. Rama can bridge into it, but it's true that we are not itself part of it. Six years ago Rama was still built directly with Tower. Later we created `tower-async`, and eventually we went our own road. This because it was clear at that point (and still is) that the tower ecosystem is not really gonna change any time soon despite rust having evolved a lot since its initial conception.
So if you like the concept of Tower, with its services and how it allows you to compose than you will also like Rama. That's however kinda where the comparison ends. Rama is a protocol agnostic network framework to build clients, servers and proxies. That is not what Tower is or its goal. Tower its only goal is provide an impl of the concept of "services". Rama uses that same concept, but its just one of many ways how we allow composition and is in a way just one of the concepts that make it so nice to build network services / network stacks.
Rama is there as the foundation to build network services. Tower is there to provide you with a way to impl the concept of Services. Tower is also a ecosystem and we keep a very close eye on it. I suggest you explore Rama a bit for yourself. A lot more will be clear to you than whatever I might say here.
I have yet to see an actual part of that policy which requires a cookie banner though. Seems more to me that it's a combination of (a) websites allowing all kind of fcked up use cases of cookies on their site (most sites do not even need cookies for real) and (b) not respecting http headers that ask to not be tracked... They much rather have a very confusing popup that kinda forces you to accept all :) How convenient.
Just like websites also give zero fcks about accept-language header... sure do geoip lookup, so much easier... not
Yes we use it for rama [1]. You can check its justfile and CI workflow file how we use it. Those run thousands and thousands of tests thx to nextest and what feels like instantly (once compiled).
Large projects build with rama use it as well. But those are proprietary from partners so sadly cannot share those.
Thank you very much for developing nextest. It is what allows our projects like rama [1] to run thousands and thousands of tests in a blink of an eye! Keep it up!
OP Here, sorry for not being clear. And happy for feedback on our presentation, docs, my article and ofc the code itself. It has been under developed since over 5 years, and was used in production right from the start. Now we are at a point that it is used by several different companies and even more individual users.
Here is some context and info about the framework that I am quoting from our README to provide you with context:
Rama is a modular service framework for the Rust (programming) language.
The framework is intentionally explicit. Your network stack is built from services, layers, transports, protocols, and state that you compose yourself. That makes the shape of the system visible in the code, instead of hidden behind framework magic or configuration.
This makes Rama a good fit not only for proxies, but for network services where the stack itself matters: how traffic enters, how it is decoded, where state lives, what gets inspected, what gets transformed, and where it goes next.
Whether you're inspecting traffic for security analysis, writing a web service, emulating clients with custom user agents, controlling connection behavior for advanced testing, or building high-performance proxies, Rama provides a clean and composable Tokio-native foundation for network services in Rust.
Rama is used in production for network security, data extraction, API gateways, routing, and other networked systems.
Yes the blog post was written completely by me. Not entirely certain what triplet you are referring to, or what that might be, but your suggestion is spot on. Going to add a comment with more context of what rama is as a comment myself. Appologies. Not yet used to promoting projects myself...
I totally get it. The triplet was ‘a framework now ready to be used, explored, and built upon by the worldwide community.’ AIs love to claim something is ready or production ready (kinda primed me for thinking AI when I read that), and the triplet is the comma-separated clause, clause, clause.
Why not email HN / dang and ask for a boost? They are very nice and sometimes do, and if it got off to a poor start but is a valuable post, no harm asking. I don’t know the Rust ecosystem enough to judge this, but, good luck.
Thank you very much. We will see, I have been on this for 5 years, if it takes another 10 years for the wider global community to discover rama, so be it. We have patience.
No clue how an AI would write it, but that is sadly how I write, sentences that are perhaps ending a bit too... late. I like my comma's and my em dashes... always have... Used to blog a lot more, trying to pick it up again, with this blog article being hopefully the first of many more to come.
And yeah mostly want to highlight the fact that is ready for production because sometimes people are worried for < 1.0 projects, but want to make sure that people know that we and plenty of other companies are already using it in production for serious projects, not just a hobby or R&D thing.
Our aim is to solve a real world problem with this, so that we can all stop reinventing the same duct-tape mess and instead have a shared foundation that we can all build upon. Such that if there is something to improve or a mistake it has to be fixed once and all rama users benefit from it. While still ahving the flexibility to use and stack your different services however you wish.
The nicest thing of Elm is how much it feels like Haskell. Have built some fun things with Elm years ago.
The second nicest thing with Elm is the philosophy of if it compiles it works. And to be honest you can get that same feeling with most of Rust as well. Sadly not as much of a haskell feeling but at least it has a warm shadow of some of its functional ancestors.
These days, though, why not just use Haskell itself? Upstream ghc cancompile to wasm for several major releases now and there are several actively developed web frameworks, some of them very Elm-inspired, e.g. https://haskell-miso.org
