wasp VS dhall-lang

The easiest way to show your support is just to star Wasp repo! 🐝 But it would be greatly appreciated if you could take a look at the repository (for contributions, or to simply test the product). Click on the button below to give Wasp a star and show your support!

Lucia is one of the open-source tools that we use under the hood at Wasp, a Laravel-like framework for React & Node.js. It has grown to 9.5K stars on GitHub since October 2023. Although Lucia itself will be deprecated as a library in 2025 and converted into a learning resource, Pilcrow is also working on other projects related to auth, such as Copenhagen and Oslo. You can learn more about his work and projects on his blog.

We have seen a lot of Wasp users facing similar challenges, thinking their toolkit was to blame. In our Discord community, we regularly help users who’ve just launched their first app with Wasp, and we've seen this issue pop up frequently. The bad news: your users and their email servers pulled a Gandalf move on you. The good news: no worries, this is something you can fix!

We’re launching a new series of posts where we'll sit down with the folks who help us run our projects without expecting anyting in return. Yes, we're talking about open-source maintainers and builders, the people who dedicate their free time to make tech better. This is our way to say "Thank you!" to all of those who help us build and improve Wasp, as well as shape the webdev ecosystem.

So what I'll do is copy the Wasp docs markdown files into their own directory within the root of the project I'm working on. Then I can reference the docs whenever I have questions or am trying to implement a new feature.

Hey, I’m Sam, a backend engineer with a lot of experience with Django. I wanted to make the jump and learn some frontend for a full stack app. I quickly experienced the arduous nature of a React-with-Django project and thought the pain was just part of the development process. However, I came across a very cool new full stack framework called Wasp.

If you’d like to check this example in more depth, feel free to check this repo here: wasp/examples/todo-typescript at release · wasp-lang/wasp (github.com). Other great place to check is their documentation, which can be found here. It covers most of what I said here, and even more (e.g. the awesome new hooks that came with Wasp v0.14)

I think you're asking for Starlark (https://starlark-lang.org), a language that strongly resembles Python but isn't Turing-complete, originally designed at Google for use in their build system. There's also Dhall (https://dhall-lang.org), which targets configuration use cases; I'm less familiar with it.

One problem is that, while non-Turing-completeness can be helpful for maintainability, it's not really sufficient for security. Starlark programs can still consume exponential amounts of time and memory, so if you run an adversary's Starlark program without sandboxing it, you're just as vulnerable to denial-of-service attacks as you'd be with a Turing-complete language. The most common solution is sandboxing, wherein you terminate the program if it exceeds time or memory limits; however, once you have that, it's no longer necessary for the language to not be Turing-complete, so you might as well use a popular mainstream language that's easy to sandbox, like JavaScript.

One other intriguing option in the space is CEL (https://cel.dev), also designed at Google. This targets use cases like policy engines where programs are typically small, but need to be evaluated frequently in contexts where performance matters. CEL goes beyond non-Turing-completeness, and makes it possible to statically verify that a program's time and space complexity are within certain bounds. This, combined with the lack of I/O facilities, makes it safe to run an adversary's CEL program outside a sandbox.

> Lambda calculus is as pure as can be, and also has terms that don't normalize. That is not considered a side effect.

Many typed lambda calculi do normalise. You can also have a look https://dhall-lang.org/ for some pragmatic that normalises.

> A better example of impurity in Haskell for pragmatic's sake is the trace function, that can be used to print debugging information from pure functions.

Well, but that's just unsafePerformIO (or unsafePerformIO-like) stuff under the hood; that was already mentioned.

I was first turned onto Pkl during my Dhall Trough of Disillusionment phase (Dhall is cool, but man is it hard) by James Ward. It looked to be a language that had enough types to compile YAML/JSON configuration files wayyyy more safely. I’ve had enough YAML/JSON misconfigurations break production, that I started looking into ways to compile those problems away, and Dhall helped a lot, but the learning curve and compiler errors are brutal to work through, and I never got excitement amongst peers. Hoping Pkl makes in-roads here.

Dhall[1] also usually gets mentioned in the same sentence as CUE.

As for Nickel, I have mixed feelings about it of the same kind as about ES6 classes and perhaps modules—we’re taking a simple language (an extremely simple one, in the case of Nix) and baking into it some stuff that the original had as a completely satisfactory library, in the name of discoverability resp. uniformity. Seems a bit sad and unnecessary to be honest. (The problem of Nixpkgs and NixOS, IMO, is not Nix the language, which is fine for the most part, but the fact that they’re a single giant monorepo with comparatively very little documentation even for the parts that basically serve as the Nix standard library.) Looks like my design sensibilities just align much better with PhD-student Eelco than with Tweag-engineer Eelco.

[1] https://dhall-lang.org/

Anyway, it is not a problem in practice that this kind of pathological function can be expressed, I just put a limit on the number of execution steps (a “gas limit”, or what the author calls “metered execution”). For keeping code simple, I think the fact that the built-in looping constructs are bounded, and recursion is awkward, are a good nudge, but in the end the most valuable tool is code review and applying good judgment.

    [1]: https://dhall-lang.org/

Fail to see how this is any different than Dhall (https://dhall-lang.org/) other than it produces plists too.

Kubernetes config is a decent example. I had ChatGPT generate a representative silly example -- the content doesn't matter so much as the structure:

https://gist.github.com/cstrahan/528b00cd5c3a22e3d8f057bb1a7...

Now consider 100s (if not 1000s) of such files.

I haven't given Pkl an in depth look yet, but I can say that the Industry Standard™ of "simple YAML" + string substitution (with delicate, error prone indentation -- since YAML is indentation sensitive) is easily beat by any of:

- https://jsonnet.org/

- https://nickel-lang.org/

- https://nixos.org/manual/nix/stable/language/index.html

- https://dhall-lang.org/

- (insert many more here, probably including Pkl)

There are underpowered languages / tools, that can only solve a problem for which they are intended poorly. But not all limited tools are like that.

Say, eBPF is prominently not Turing-complete, which allows to guarantee that a eBPF program terminates, and even how soon. Still eBPF is hugely useful in its area.

Or, say, regular expressions are limited to regular languages; in particular, they famously [1] cannot process recursive structures, like trees. Still tools like grep / ag / rg are mightily useful.

Yes, I agree that YAML is underpowered for proper k8s configuration! But it's also too powerful for its own good in other aspects [2]. I wish Google used Dhall [3] or their own purely functional config language (FCL? I already forgot the name) instead of YAML; sadly, they did not.

[1]: https://stackoverflow.com/a/1732454/223424

[2]: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...

[3]: https://dhall-lang.org/