I admire the consideration Richard and the rest of the Roc community put into the language, but I'm curious whether the absence of macros will unavoidably lead to code like https://github.com/agu-z/roc-pg?tab=readme-ov-file#examples . It's not obvious to me that the benefits of that constraint (teachability, language tooling) outweigh the costs of writing code that probably should be automated.
That said, I may just be showing my lisp bias, and tools like Squirrel in Gleam are sufficient https://hexdocs.pm/squirrel/
The README examples showcase the low-level API, but I've also made an experimental query builder that lets you write type-safe queries without the boilerplate. There’s a CLI that generates a Roc library from your database schema, that you can use through a DSL to build up a parametrized SQL query and decoder at once. See an example [1].
You’d be surprised at how nice you can make a DSL in Roc without any metaprogramming!
As for Squirrel, I think it’s a great approach and definitely something I might explore in the future. Right now, I'm leaning towards a DSL for better reusability, though I must admit, that actual SQL is hard to beat!
Since I'm not familiar with Roc and am looking at example code that has an unknown amount of boilerplate added or removed compared to normal code...
What part of that example is bad, and the lack of macros means it stays bad? I can come up with some possibilities (e.g. response mapping), but I have no idea if they're valid or not because I don't know if that's just due to being an intentionally explicit example.
As a general note, the code there is an initial more exploratory api. It definitely could be simplified (solid bits of extra noise in it).
That said, it does have the fundamental issue of the query is just a string and the code author has to fundamentally deal with correctly specifying what the return type is. Technically a fancier query builder could be defined that removes the sql and instead defines both the query and return type at once to avoid the double specification.
Otherwise, something like squirrel would 100% be doable in roc. [Something similar](https://github.com/isaacvando/rtl) already exists for templating in roc via code gen.
roc is the language most rust nerds really want but don’t realise yet. functional, modern tooling, fast enough for almost everything (~ go / swift), and without the insane complexity and cognitive overhead of the borrow checker.
My point is more that many rust programmers like rust because it’s an ML not because of the borrow checker. Most cli apps / web services are probably better off with a high performance managed runtime (go & swift are good examples of imperative languages that have successfully made similar tradeoffs).
There do of course exist many important use cases where a better c++ is actually what you want, and the complexity tax of that is worth paying.
Does Roc have escape hatches for mutability? That's something I value in Rust, good escape hatches from the borrow checker, so if something gets too difficult, you can just `Arc<Mutex<RefCell<T>>>` it.
yeah that seems cool! I'm a little skeptical of pure functional programming with no escape hatch. I rarely need the escapes in Rust but when I do, I really do.
That's right, although the Rust equivalent of that would be more like `Future<Arc<Mutex<RefCell<T>>>>` than `Arc<Mutex<RefCell<T>>>` - so the ergonomics would be a bit different!
Interchangeable "platforms" seems like a fantastic idea! Unfortunately there is ZERO documentation on how to develop your own. For me, personally, this is the last barrier for adaptation!
Please asap! Love this project!
There are some major changes to platform development that are coming (both flexibility and usability). Sadly, they have been slow to introduce. I think that is a large part of the reason the documentation doesn't exist. Right now writing a platform is a much harder process than it will be in the future. Until a certain chain of features land, I expect this to stay as bespoke knowledge that is obtain through modifying examples and asking questions on zulip.
Firmly on the side of effects: Roc doesn’t have higher-kinded types, which makes it practically impossible to express monads. It’s covered somewhere in https://www.roc-lang.org/faq.html
You need them to express a type constraint that’s generic for all monads. I might have gone a bit too far saying monads would be impossible without HKTs, but a single Monad type class would be, and you lose a lot of the power of monads if you don’t have that.
That said, I may just be showing my lisp bias, and tools like Squirrel in Gleam are sufficient https://hexdocs.pm/squirrel/