Roc - A Functional Language looking for those Software Sweetspots (with Richard Feldman)
Vložit
- čas přidán 19. 12. 2023
- Sometimes, what a programming language makes harder is just as important as what it makes easier. For a simple example, think of GOTO. We’ve been wisely avoiding it for decades because it makes confusing control flow desperately easy. Types and tests are other examples - they’re as much about specifying what shouldn’t work as what should. And perspective is what makes this week’s topic particularly interesting: Roc is a language that’s functional, fast, friendly, and extremely interested in making your life easier by enabling some possibilities and restricting others.
So this week we’re joined by Richard Feldman, the creator of Roc. He’s been an advocate of the Elm programming language for years, for its tight focus on taking the best bits of Functional Programming to the browser. And in recent years he’s been inspired to build his own language, taking that philosophy to other places and platforms.
But which bits are “the best bits”? And how do they change when the domain you’re coding for changes? How is Roc built and how would we build systems in it? Let’s find out…
--
Roc’s homepage: www.roc-lang.org/
Richard’s GOTO Copenhagen 2021 talk: • Functional Programming...
Richard on Twitter: / rtfeldman
Kris on LinkedIn: / krisjenkins
Kris on Mastodon: mastodon.social/@krisajenkins
Kris on Twitter: / krisajenkins
I JUST discovered this podcast the other day, watching the Zig episode, which I thought was amazing, and immediately subscribed. And now the first new episode to come out since subscribing is about Roc, which I also recently discovered and was just looking into the other day! Very excited to watch.
To Kris: you have a soothing voice and are really kind and attentive with guests which makes this show a joy to watch/listen to. I also love how much the interviews seem to have real curiosity and joy in coding. A lot of programming content I see on youtube sometimes just gives me bad vibes, even when the content is good, bc the framing can be so focused on like… the business and career side of things, making money, and the like. I know that’s important too, but as a hobbyist that likes looking into coding stuff way above my level just bc i find it genuinely fascinating, this show has been a breath of fresh air.
I can relate so much to this comment, it's scary!
Wow, what can I say except thank you! That's very kind of you to say. I'm glad if my joy and curiosity for coding is finding like minds. 😊
Oh, what a nice surprise.
I've been following Roc for quite a while now and I love the mission statement that Richard is going for.
Super excited to see what the two of you have to say!
Another fantastic video!! Love the idea of having a simple FP language to use in whatever domain I want. Especially if platforms end up being straight-forward to make.
Yay! Two of my favorite speakers!
About the discussion at the end about `http-low-level` package being used to define an interface: it looks a lot like Haskell's Backpack signatures, which are themselves heavily inspired by ML's Functors.
Another great episode, thank you!
Very interesting! I think I'll look into this further and talk to some of the ppl in that community cus i think this might be able to help me with a project i been thinking about. Awesome video!
I only just noticed how genius the thumbnail for this video is. I hope it doesn't go unappreciated.
Ha, glad you like it. Sometimes I do little things like that and wonder if anyone gets it or if I'm just amusing myself. 😅
great episode, an early christmas present !
Definitely need to know which papers to read, to learn how to make a programming language
I can offer a couple of recommendations. I learnt from SICP, which is coming up to its 40th anniversary, but I think it still holds up as a great intro. And Luca Pette was recommending Crafting Interpreters in the recent TypeStream episode.
SICP covers compilers as well as interpreters, but it's assuming a Lisp-like language so teaches almost nothing about parsing. I'll let you decide whether those are pros or cons. 😁
en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
craftinginterpreters.com/
simplification and minimal tooling for the job
nice! the other day I thought of solving AoC with Elm, but got frustrated and gave up after failing to work out how to simply print out to terminal without running a website :)
Ha yeah, I can understand that. It's possible, but sometimes in Elm it seems easier to print to a webpage. 😅
Gamedev with functional style. Show me and I believe it.
there are libraries for game development in common lisp and haskell. also i think there are opengl and sdl bindings for functional programming languages
@@delibellus I know, those bindings probably exist for brainfuck as well. That's still not saying very much. Even the almighty Rust is on the edge whether it should be considered a viable language for gamedev.
@@meanmole3212 guess you haven't heard of veloren?
@@fiona9891 Not developed with functional style.
there’s a talk where john carmack says haskell is the best language for game dev
I believe I need a platform definition to have my verbs defined to accomplish the last task in Roc :p
I hope even if the language goes nowhere, RF is still going to get something out of it. reputation, something.
4:20 ... Needing to do *paid work* is the problem. 🙂
Repackaging of repacked ML. Both StandardML and especially Ocaml are proven in many domains.
Java had and still has an app server concept , the industry goes on another cycle
thank you for another good talk krish. I kind of don't like the Roc language after trying it for a while because it tries to emulate the elm and it fails spectacularly, it literally fails at everything it tries. I also don't like what the community did to Evan and elm in general. other than its not the worst the language I've come across.
I was into Elm a while ago and left because of his attitude. I think Evan did it to himself.
I like the ideas behind Roc, but looking over the builtins, it seems extremely confused in its inspirations. Container functions seem to be "a collection of my favourites" rather than following any sort of rhyme. Strings purport to reduce emoji bugs by operating on grapheme-clusters instead of codepoints, yet the docs aptly demonstrate that this helps not with emoji at all - and there's a fold over raw UTF-8 bytes too, for some reason (am I expected to re-parse the UTF-8? Is this for sending over the wire? Who knows?) Another absolute banger is having a menagerie of number types of every size... and also a confusingly called `Nat`, which seems to be `size_t`, the worst C++ numeric type, that you're limited in doing arithmetic on and that has unknown size. It relies on compiler optimizations to modify lists in-place, but there's also `withCapacity`/`reserve` which expose internal memory management (and only work properly if the reference you hold is unique, so much for opinionatedly not having linear types).
Reminds me a lot of Gleam - tries to do all of the nice things at once, kind of falls short everywhere. A passion project, but lacks good design, unfortunately.
In what world is size_t the worst C/C++ type lmao
@@thebatchicle3429 cited as frequent source of signed/unsigned bugs. A little better in Roc since it doesn't seem to have implicit conversions, but I dunno. "Pointer-sized integer" is a useful concept, but maybe calling it after natural number is some very poor nomenclature. Not to mention that Roc's string parsing clamps the result to bounds instead of returning an error... My CVE senses are tingling.
@@thebatchicle3429 although that's fair enough - the worst integral type is probably `int`, whose size is "screw you, it depends on the compiler and the OS".
Here are my rough understandings about the various points. Many I think are just part of the language being so young.
> Container functions seem to be "a collection of my favourites" rather than following any sort of rhyme.
Container functions definitely have been added as needed. The language is early and there hasn't been a chance to just add all possible functions. Also, we generally learn towards not adding a function until it is needed. Also, we tend to try and pick what reads the clearest rather than just copying all container functions from elm or something. Definitely understand the frustration there.
> Str
Long term, we want to have a full featured unicode library that is separate from the builtin library. This enables it to update separately from the Roc compiler. Fundamentally, most languages have unicode and locale related bugs in there standard libraries. This leads to people writing incorrect code by default. In order to help users be correct by default Roc is trying to build this differently. That said, all this safety work is just in the early stages and little has been built for the complexities of unicode and locales. We are mostly trying to avoid bad designs currently.
> and also a confusingly called `Nat`
Nat is actually planned for removal. We will still have all of the sized number types. Sized number types are quite important for performance.
> It relies on compiler optimizations to modify lists in-place, but there's also `withCapacity`/`reserve` which expose internal memory management
I really don't see the issue with this. If you know you are going to build a list of a specific size, why would you not want to use `withCapacity`? I may be too much a pragmatist, but giving users enough control to write performant code is important. This is dealing with reality rather than trying to hide every detail away from the user at the cost of performance.
> and only work properly if the reference you hold is unique, so much for opinionatedly not having linear types
This definitely is an interesting point of contention. Linear types add a ton of complexity to the language for a very specific guarantee. The question is, do you need the guarantee enforced by the compiler? In most cases, uniqueness tracking just works and users get a great experience. There definitely are edge cases that will hurt performance. Personally, I would probably prefer linear types. That said, it is not hard to profile code in order to ensure values stay unique (hopefully will become trivial with more tooling in the future). Also, I fundamentally am coming from lower level languages to Roc. Most users are coming from higher level languages to Roc. Simplicity with generally high performance may be the right tradeoff form most users.
@@brendanhansknecht4650 Hey, thanks for the constructive reply! Hope you didn't find my writeup too rough.
Glad to know stuff's being done about the strings! Might wanna reduce the API surface though - IMO there's no reason to have byte fold when you have a cast to byteslice that's elidable. A little more strain on the compiler I s'pose.
Agree on the sized types - refreshing to see this bit of really solid pragmatism in a functional language.
Re linear types: one thing I would look into is a linear type system that has the "promote linear to universal" operator, normally denoted by little square in linear logic. (And inverse is also possible, something like `uniqueCopy` that might actually do a copy behind the scenes or could get compiler elided). That way, you have a way to express uniqueness and make sure the compiler optimizations trigger, but can opt out at any moment. Hell, you can even make linear types decay to universal types automatically - I don't think I've seen that done much, but would be a fun experiment.
Linear types in general let you have nice things like in-place mutation of maps/objects and whatnot without breaking the functional language rules - having mutation mechanism "built-in" definitely solves a lot of "insufficiently smart compiler" performance issues FPs can have.
Johnny bairstow