unison VS dark

Hi, one of the Unison creators here. We've talked about adding pluggable syntax[1]. It's in principle straightforward (the code is already stored in a database as its abstract syntax tree, not text) and I imagine a future version of Unison could let you pick from a variety of syntaxes. But we haven't gotten to it yet.

[1] https://github.com/unisonweb/unison/issues/499

... that said, the language semantics and libraries are still going to be different, so even if we have a python-ish or typescript-y syntax, there'll still be new things to learn. :)

Short version: no type classes (yet)

Longer version:

Building upon what Quekid5 mentioned, Unison abilities are an implementation of what is referred to as algebraic effects in programming language literature. They represent capabilities like IO, state, exceptions, etc. They aren't really a replacement for type classes, though in some cases you can shoehorn abilities in where you might otherwise use a type class.

For someone coming from a Haskell background, I think that abilities are closer to a replacement for monad transformers. But in my opinion they are much more ergonomic.

Discusson of type classes comes up a lot. Here is a long-standing GitHub issue: https://github.com/unisonweb/unison/issues/502

For what it's worth, I've written Unison quite a lot over the past few years and while I've missed type classes at times, I think that reading unfamiliar code is easier without them. There's no implicit magic; you can see exactly what is being passed into a function. So far I've been happy with a bit more verbosity for the sake of readability.

I've been following the Unison lang [1] for quite some. Wing seem to set similar goals? From the first glance Wing looks more polished, but there's "The Big Idea" behind Unison - is there something similar?

[1]: https://github.com/unisonweb/unison

in haskell it looks like this, you specify the language extensions you want at the top of the source files: https://github.com/unisonweb/unison/blob/trunk/unison-core/src/Unison/ABT.hs

I think Unison is going in this direction. Imo this is a mistake, as a program language functions not just as specification for the machine, but also as communication between programmers. Allowing the introduction of arbitrary dialects to suit individual preferences seems like it would interfere with that communication.

The Unison language [1] also has a very interesting effect system.

[1] https://github.com/unisonweb/unison

I think Unison might have at keast somewhat similar features to what you talk about with package manegement and possibly modules. I haven't tried it out yet but from the documentation it sounds similar.

Yes. Darklang was originally in OCaml using js_of_ocaml, and we ported it to F# using Blazor (https://github.com/darklang/dark/tree/main/backend/src/Wasm). It works.

We found that in dotnet 6, the code was much slower, with long startup times and a much bigger download, than in js_of_ocaml. It also had a lot of issues in running in a Webworker, which wasn't the case for js_of_ocaml.

In dotnet 7, the webworker issues are better and AOT is easier, so startup is faster. Download sizes are still bad, and it's still slower than js_of_ocaml.

However, dotnet allows almost any code to run in WASM, which js_of_ocaml had large limitations. This meant a decent chunk of functionality had to be worked around to make separate js vs native targets, which also was a massive pain and took a long time. Dune's virtual targets wasn't ready at the time - I think we were one of the test cases for it.

First it was probably Dark. They made a lot of noise some years ago, but then I never heard of them again (looking at their current website, looks like they moved on to AI now, obviously).

Specifically Unison and Dark?

Reminds me of Darklang. Personally, I don't think vendoring cloud services into a language is going to be beneficial. I'm curious how the language deals with vendor updates. Do I have to upgrade the language then? If so, I see a lot conflicts coming from this. Then it comes down to Javascript or HCL, the HCL bit makes me think that the below statement is not as truthy as it is on the surface:

I wish I could remember what took me to YCombinator's website on the 10th of October, 2022. That was when I first heard about Wasp and another language called DarkLang. After I learned about Wasp, I was intrigued and curious to know how it works, which led me to join the discord server the next day.

Some languages that try to integrate an HTTP server and a database:

Ur/Web: http://impredicative.com/ur/

Dark (Darklang): https://darklang.com/

There are others in this space I did not assess like Encore, Shuttle, Modal, and Dark. These were not assessed for the sake of time. If you're interested in IfC, I encourage you to take a look at these others.

Oh, finally! I was waiting to build my serverless CRUD webapp in Dark (OCaml + JavaScript and Fsharp?) until they had support for returning negative numbers on a GET request!

The author should check out Dark Lang: https://darklang.com/

Darklang - Main project license does not appear to be Open Source, very limited rights provided.