Hey folks, hello!
I recently started to play with Roc and got amazed about the Platform concept.
I was thinking about doing something really similar for .NET, kind of creating a purely functional language and use .NET to interact with the outside world(just for fun, not a real project tho).
But then, I found the Roc language and figured that if I wanted to do that, the language was already "ready to use" I would "just" have to write the .NET platform binding for it.
I started a git repo with it, and if I'm able to get anything working, I will open a PR on the roc examples repo with my basic experimentations.
Sounds awesome :)
nice, welcome! :wave:
we have some examples of interop to other platforms, including JVM - they're basically all Hello World levels of completeness, but they might be helpful to get up and running!
fair warning, the tooling for generating bindings to different low-level targets is better than it used to be, but the ergonomics are not great yet :sweat_smile:
Richard Feldman said:
we have some examples of interop to other platforms, including JVM - they're basically all Hello World levels of completeness, but they might be helpful to get up and running!
Yep! I'm using it as example while also using the simpler version from the examples repo.
So much to learn about C ABI, but luckily I will have at least an example to share :)
awesome, feel free to ask on Zulip if you have any questions! :smiley:
So, one thing that is really bugging me:
If my .NET platform has the ability to, lets say, send http requests, is there any pattern from Roc that I can follow so I can implement it?
For example:
I noticed that the roc-pg requires the platform to implement the TCP effect.
But how do I know, in my platform, the "correct way" of implementing the TCP effect?
My concern is that if I implement the Tcp.withConnect
with a different name like Tcp.usingConnection
or something similar, the package won't work in my platform?
Edit: I actually just found the hosted
module type, but in the docs it says that it is "likely to be deprecated soon".
Probably this is the thing that I'm looking for?
@Agus Zubiaga is currently working on implementing the Module Params proposal. I think this is relevant as in the near future platform will actually pass effects into the modules, so all modules will be platfrom-independent by design.
In this way the specific name is not important, moreso the type signature and behaviour. You can always wrap the effect before passing it into the module if you want to customise the behaviour somehow.
lovely. Thx @Luke Boswell !
So the idea is that platforms will only need to implement the lowest level primitives, and the roc library ecosystem will sit nicely on top of that (across all the platforms).
Yeah, roc-pg being a package, is not supposed to be able to import from the platform like it does. It’s kind of exploiting a bug right now :big_smile:
As Luke said, module params is how we are going to solve this problem. The app explicitly provides the effects to the package, which allows it to adapt them if they don’t quite match the types provided by the platform or even mock them for testing purposes.
I did it \o/
I was able to the same as we have in the go examples https://github.com/roc-lang/examples/blob/main/examples/GoPlatform/README.md
But with .NET https://github.com/iuribrindeiro/roc-dotnet-platform
Took me a few days and I still don't understand too much about what is going on there regarding the C functions interop since I'm still learning this. 0 C experience here.
But it is working and I'll open a PR to a new .NET example and still playing around it :)
yooooo congratulations, that's awesome!!! :grinning:
hey folks, should I PR this into the roc repo under the examples folder or to the examples repo?
Examples repo sounds good :)
Anton said:
Examples repo sounds good :)
Will this be automatically part of this page once/if it is merged?
https://www.roc-lang.org/examples
Once it is merged and any PR is merged into roc-lang/roc because that's when website updates are triggered.
Last updated: Jul 06 2025 at 12:14 UTC