Roc Lang – Elm but for everywhere [video] | Hacker News Reader

Roc Lang – Elm but for everywhere [video]

youtube.com

63 pointscrowdhailer34 comments

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/

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.

Heard squirrel is well cool :P

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.

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!

[1] https://github.com/agu-z/roc-pg/blob/62725fe3a1d92144a8408ae...

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.

So excited to see it continue to thrive and grow.

Automatic memory management seems like an antifeature if you look from a systems language perspective (rust).

And I'd argue the borrow checker reduces the cognitive overhead.

Not when one looks it from the perspective from Xerox PARC, ETHZ, DEC/Olivetti, Microsoft Research, Apple on systems programming.

Sure, you can cherry-pick your perspective to fit your needs.

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.

I don't think so (could be wrong), but it does perform optimistic mutation on your functional code.

There is a talk somewhere where Richard "demos" this.

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.

It isn't "no escape hatch". It is platform dependent escape hatches. A platform can give you full access to mutation and libffi if it wants.

It should be possible to have a platform that has a mutable reference with an API like this:

    main = 
        x = pf.NewRef!
        pf.Write! x 5
        y = pf.Read! x

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!

Haskell:

    import Data.IORef
    
    main :: IO ()
    main = do
      x <- newIORef (0 :: Int)
      writeIORef x 5
      y <- readIORef x
      print y

I'm a rust nerd and love roc, the problem is my employer won't let me use either.

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.

Does anyone know if roc fell down the blessed packages issue elm did? That was a major turn off to any interest I had in elm

Can you elaborate on what "blessed packages issue" is?

Elm allowed only certain packages to use some restricted apis as it was seen as a clique and rubbed people the wrong way.

I'd say Elm fixed packages. Only uses what is needed and detects API breaks.

This is one of the things Roc does differently from Elm. Roc packages all work the same way, and you get them from URLs.

Can someone explain where Roc sits in terms of monads vs effects?

I don't have a PhD but I would say effects.

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

How do you need HKTs for monads?

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.

You can do monads without HKT but it is much more manual. You need to compose monad transformers yourself, for example.

Side effects are monadic (the main side-effectful abstraction, Task, is the continuation monad). There are no algebraic effects.

Does Roc lang actually do web frontend, like Elm?

It can do web front end. but it's not focusing on it in the way Elm does

Reply on news.ycombinator.com