Roc - A Functional Language looking for those Software Sweetspots (with Richard Feldman) 

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. 😊

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. 😅

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/

Ha yeah, I can understand that. It's possible, but sometimes in Elm it seems easier to print to a webpage. 😅

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

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.

I was into Elm a while ago and left because of his attitude. I think Evan did it to himself.