Stream: beginners

Topic: Proliferation of platforms?

Eric Rogstad (Jun 19 2026 at 16:55):

Tobias Steckenborn said in #show and tell > Roc TigerBeetle Client:

Yeah, but that’s the same for example for Redis and the like, right? I‘m just wondering right now each underlying „library“ seems to be done as as platform. That to me seems to lead to fracture of the ecosystem as you by chance would need to find something that has exactly your stack which is unlikely which in turn would be more or less the requirement to also know platform dev :sweat_smile: but might be mistaken here

I had a similar question to @Tobias Steckenborn. The answers in that thread help, but the picture still doesn't seem totally clear to me. Has there been anything written up that walks through different scenarios and explains where the app / platform boundaries might be?

I'm imagining something like, "Suppose you're making a de novo enterprise SaaS CRM product, and you want to do it in Roc. Assume you're using postgres, websockets, other random technology. You would likely use a platform that provides these XYZ components, and then import these ABC pure Roc libraries."

I wouldn't necessarily expect anyone to have written that kind of thing, but I'm just curious if anything along those lines exists. Because as it stands, I'm finding myself unclear on how much we expect platforms to standardize, vs, on the other extreme, every non-trivial app or service needing its own platform.

I think I've heard RF say that a platform is kind of like a framework. So instead of setting up a Node.js service running an Express web server, I'd use some Roc web server instead. But what happens when I want that web server to talk to Postgres, or Redis, or Kafka, or some new technology that doesn't exist yet?

Is the answer that as long as the technology uses a standard protocol, I'll likely be able to keep using a standard platform, as per Luke's comment here?

Luke Boswell said:

same for example for Redis and the like, right?

I think Redis is a TCP socket, with a custom protocol over it... so any Roc platform that provides a TCP primitive will be supportable

If so, then besides needing to use a non-standard protocol, what other reasons might drive me to need a custom platform? Has there been anything written up on when you should expect to need a new platform, vs just importing a Roc library?

Thanks in advance for any guidance that folks can provide!

Eric Rogstad (Jun 19 2026 at 17:21):

Ah, this (and following comments), seem to suggest platforms won't need to proliferate as much as I was fearing. Still curious if anyone has tried to model it out in more detail though.

Richard Feldman said in #show and tell > Roc TigerBeetle Client:

it's always been part of the plan to have hosts be able to bootstrap the ecosystem - in other words, at first you reuse existing C/Zig/Rust/etc. code in the host to provide that functionality, but then later you want a pure-Roc, platform-agnostic version, which motivates doing that implementation

Tobias Steckenborn (Jun 19 2026 at 17:51):

Yeah, to me right now also not fully clear. Especially if cross deployment targets… seems like right now a lot is depending on the platform authors and some sort of super platform of there‘ll not be a massive amount pf competing be similar ones 🤷🏻‍♂️

Tobias Steckenborn (Jun 19 2026 at 17:52):

And that all of the different ones use the same „interfaces“ for compatibility

Anton (Jun 19 2026 at 18:06):

Sidenote: I made an issue to add this to the website FAQ.

Norbert Hajagos (Jun 20 2026 at 06:56):

If a platform wants to give you a ton of control, it can. It could even give you access to OS specific primitives, at which point it could be called "The LibC platform". Direct access to unix sockets, spawning of threads to run a roc function on, concurency primitives. It wouldn't be a nice platform to work with, would have panics in the platform code when running on a different OS than intended, would be filled with effectful functions, but that would be all the capabilities you need.
I'd guess platform authors would try to do power-optimizaton. "What is the least amount of power I could give to the app author that would satisfy all their needs?" I think this will be hard, and a long process, but I don't see a future where the answer is always "you need to write your own platform".
The problematic exceptions are (I think)

• cpu performace oriented native libraries around math, machine learning, cryptography (we talked about that one being in std). The sheer perfomance of hand-written assembly, optimized over decades can't be matched by roc.
• big, useful libriaries that are so establised and might go along an application, but are not the core of it. A graphics lib would be planned for by the platform author, that doesn't count. Honestly only sqlite comes to mind, but there must be more. I heard treesitter is a C lib as well, maybe if you wanted some syntax hl in you game, cuz you're making a programming game, that would throw you off. The chance of these being rewritten, and the usefulnes it would bring approaches zero, so I'd imagine established, more generic platforms would allow you to do C FFI so there wouldn't be need for a platform like: django, django-sqlite(this specifically would be present i think, or just default be part of the base platform), django-math, django-ML, django-ffmpeg

Richard Feldman (Jun 20 2026 at 11:49):

cpu performace oriented native libraries around math, machine learning, cryptography (we talked about that one being in std). The sheer perfomance of hand-written assembly, optimized over decades can't be matched by roc.

yeah cryptography should be in the stdlib for multiple reasons, e.g. handwritten assembly not just for performance, but to make sure they aren't susceptible to timing attacks

regarding other math in general, I think we don't know, but it's plausible that we can be competitive if we have certain primitives in the stdlib. We'll see. :smile:

regarding machine learning, it's really hard to imagine Roc being used for that use case because "R-o-c" is not spelled "P-y-t-h-o-n" and that seems to be a hard requirement in that domain :stuck_out_tongue:

Richard Feldman (Jun 20 2026 at 12:03):

(see for example Mojo)

Richard Feldman (Jun 20 2026 at 12:05):

I'm not saying we should completely ignore machine learning (or for that matter data science) or anything like that, but rather that I don't think it makes sense to add language features to try to be competitive in those domains given how notorious they are for being Python monocultures :sweat_smile:

Richard Feldman (Jun 20 2026 at 12:05):

or at least, big language features

Richard Feldman (Jun 20 2026 at 12:05):

if there are small changes that could make a big difference to those use cases, that's different

Brendan Hansknecht (Jun 20 2026 at 20:23):

If you squint really hard and ignore large parts of the industry the python monoculture is breaking.

More of more stuff is changing to:
use python to define and compile a model to a binary.
In production, run the final binary in a rust wrapper (so no python in what is running in production)

There are other similar cases in many places....but definitely the more common trend when looking as a whole is that more and more python is wrapping rust libraries rather than the python layer going away.

Brendan Hansknecht (Jun 20 2026 at 20:25):

As t the same time... People are abandoning raw cuda c++ for weird DSLs in python for GPU programming. So so so many are popping up. Almost like cuda was designed for gpus from 2006 and no longer is good for modern gpus.

Brendan Hansknecht (Jun 20 2026 at 20:25):

But yeah, I still vote roc would have an exceptionally hard time breaking in here in a meaningful way

TeaDrinkingProgrammer (Jul 05 2026 at 13:35):

I agree there, Python seems to be moving towards being an interface language of sorts, where the "end-user" programmer is writing in Python, but library code is a Rust core with some Python glue code. For tooling, things seem to be moving to 100% Rust:

• Uv (new package manager) is 100% Rust
• Ruff (linting) is a Rust library at its core
• Pydantic 2.0 (type validation) uses Rust for the validation core and also uses Rust regex by default

Like other people already mentioned, nearly all ML and math packages are either C or Rust.

Anton (Jul 05 2026 at 14:00):

It's a nice a real world demonstration of something similar to our platform split.

Elijah Immer (Jul 05 2026 at 15:04):

@TeaDrinkingProgrammer I would like to note, that’s how Python has always been (from what I know at least). All the (good) Python libraries have always been written in C (or similar), or are bindings to a popular C library with a little bit of Python glue (I have seen some „Python only“ projects, but I think those are mainly just commenting on issues with the binary package delivery and building (more of lack-thereof for the latter from what I understand)). I have heard the sentiment that "the role of a Python developer is to make sure Python never runs“ because all the big logic should be in these low level libraries (for a large part because Python is so slow).
Another part of python I think is that you don’t have to recompile a huge project every time (slow compilers suck). You just precompile your libraries and link to them at runtime through Python, and you avoid the compilation step of your program along with linking it to your 4,000,000 lines of dependency code (assuming they used the same dependencies as in the Python version, they might have more). Those libraries end up being effectively platforms with less control over the runtime. A good example could be something like Flask (but I don’t know much about the innerworkings of that.)
Another example, and kind of how I’ve been thinking about Roc, is like a more performant version of Lua (in a way). Lua is typically used as a way to add things or interact with a very large program. Those programs are often effectively platforms, where they set it all up, run Lua to configure it, then do their thing and call the Lua code for the bits of logic they want to be able to change. Some platforms are like Hyprland, using Lus to handle configuration and event responses, and Roblox using Lua for, basically everything (I don’t know much about the latter)

I also think tooling has been moving to rust because people have started to realize that you want fast developer tools (such as compilers)… and rust just feels so much more approachable than C (at least it did for me when I started).
(This also feels a little ironic given how slow rust compiles…)

Last updated: Jul 23 2026 at 13:15 UTC