dream VS swift-async-algorithms

> It sounds like you read my statement as "run the exact same code in node or OCaml" which I agree would have been very hard.

Hello! Indeed, I did misunderstand you. I agree that it was possible to share some parts of the code between Reason's JS target with BuckleScript, and native target with the stock OCaml compiler. I think a pretty reasonable number of people did that. Actually, it's still possible to this day even with ReScript e.g. https://github.com/aantron/dream/tree/master/example/w-fulls...

> Between the breaking changes and the general change in development philosophy...switching to the ReScript compiler for my project would have required nearly a complete rewrite.

There were perhaps a couple of minor breaking changes but can you explain why it would have required a near complete rewrite? I wasn't aware of anything major like that. ReScript even supported and as far as I know, to this day continues to support the old Reason syntax.

> you might want to check out OCaml for general purpose programming

Any tips on backend frameworks to look at? I need to write a small websocket service for a side-project and have always wanted to try OCaml. I came across https://github.com/aantron/dream.

The framework I played around with for OCaml was called Dream: https://github.com/aantron/dream. I think it had built-in support for auth, but I didn't use it in what I was doing. I also barely scratched the surface of what it supported. On the whole, it seemed really nice though. The biggest issues I had were figuring out OCaml since I'd literally never used it before and figuring out how to make an HTTP call from within OCaml since the documentation can be iffy. Thankfully, Dream's documentation was actually reasonably good.

Yes. OCaml + all of the 3 OCaml-to-JS compilers support OCaml syntax.

Dream itself demonstrates:

- Server and client both written in Reason, using ocamlc+Melange https://github.com/aantron/dream/tree/master/example/r-fulls...

That example could also have been written in OCaml syntax, because ocamlc (native) and Melange (JS) both support OCaml. However, Reason is nicer if you want to use React with JSX.

- Server and client both written in OCaml, using ocamlc+Js_of_ocaml https://github.com/aantron/dream/tree/master/example/w-fulls...

The remaining example uses Ocaml on the server and ReScript on the client, using the ReScript compiler. However, you could use OCaml on the client with the ReScript compiler. Just as with Melange, you would lose access to nice JSX syntax https://github.com/aantron/dream/tree/master/example/r-fulls...

It's definitely a lot and not user-friendly to have to decide between all these options, but the community is experimenting greatly right now... so it's good and bad, and that's how it is :/

As for Node.js, using ReScript syntax requires you to use Node.js on the native side, but that is the only coupling. If you write your native side in OCaml or Reason, you can compile it to native code with ocamlc (technically, ocamlopt is the internal command; nobody uses either one directly, but the build system calls them).

Last weekend, I started reading up on Swift Concurrency through the use of async-await, actors, etc... I really liked what I read and thought of converting my current code to use these new Swift Concurrency tools and ditch the GCD. I used continuation to convert all methods with completion handlers from the Device class to async throw methods and turned Device into an actor in order to protect some members from race conditions. Once more, I am faced with the issue of calling the async methods of the Device actor one by one (waiting for each ones completion before starting the next one). I spent a lot of time thinking on how to do this and came across a number of useful references such as this one and this one. I tried to think of ways of implementing such a channel in my controller class, to guarantee sequential execution of different tasks that require the underlying library, but I'm facing a few issues with this approach:

AsyncStreams also now has the associated AsyncAlgorithms library https://github.com/apple/swift-async-algorithms which covers a lot of the Combine features (debounce, merge zip etc.)

You might find the treasure trove known as Swift Async Algorithms and look at their test suite.

https://github.com/apple/swift-async-algorithms

Requires Xcode 14, which is still in beta and cannot push to the App Store.

Also, Apple fucked their back port badly. It’s supposedly fixed now, but if you built an app that used async/await anywhere in Xcode 13.X and a user installed running iOS 12/13/up to 14.5 they’d crash on launch.

So I personally wouldn’t trust it, and instead just push to raise your iOS minimum. I’ve had no problems requiring iOS15 in my projects over 1M installs

Asynchronicity is only one aspect of Functional Reactive Programming. You’re comparing single values vs. multiple values. AsyncStream is a better analog, but I’m pretty sure you still need to bring in swift-async-algorithms to have an apples-to-apples comparison.