Does Roc have any features that a Haskell programmer could consider improvements?
strictness!
Roc – A fast, friendly, functional language
111–120 of 180 posts
Re: Roc – A fast, friendly, functional language
#112I'm super keen to see how Roc pans out, because it sits at an (IMO) riveting spot in the space of PL design tradeoffs: 1. The typesystem will be sound, ML-like, and so simple that any code that doesn't interact with external data will not need _any_ type annotations. 2. An aim to make it the fastest managed compiled lang around (faster than golang). 3. Functional. 4. A focus on fast compile times from the beginning (…
Glad you've been enjoying Software Unscripted, thank you for the kind words! > 1. Whether they'll support macros, The plan is not to support macros. A major reason is that macros tend to conflict with editor tooling, and I definitely have big plans for Roc's editor tooling! > 2. Whether their decision to build a whole new IDE will take away from the work that will go into an LSP (it will take a lot to pry away neovim…
> The plan is not to support macros. A major reason is that macros tend to conflict with editor tooling, and I definitely have big plans for Roc's editor tooling!
I disagree! I've been working on a macro-heavy Rust project with both proc and declarative macros and the tooling makes them better. I'll add that there is immense value in turning repetitive code into "spreadsheet" style tables of data as well as being able to combine const expressions to get user controllable compile-time errors.
Re: Roc – A fast, friendly, functional language
#113I'm super keen to see how Roc pans out, because it sits at an (IMO) riveting spot in the space of PL design tradeoffs: 1. The typesystem will be sound, ML-like, and so simple that any code that doesn't interact with external data will not need _any_ type annotations. 2. An aim to make it the fastest managed compiled lang around (faster than golang). 3. Functional. 4. A focus on fast compile times from the beginning (…
> 1. The typesystem will be sound, ML-like, and so simple that any code that doesn't interact with external data will not need _any_ type annotations. I've tried using languages with this promise, such as Haskell, and also spent a lot of time with TypeScript, which makes a different set of tradeoffs, and I feel like I've spent enough time on both to know this is the wrong tradeoff to make. It sounds flashy to be able…
Rust takes the "at least annotate all your function signatures" approach as well. It's essential for making borrow-checking tractable (for both the compiler and the programmer).
Re: Roc – A fast, friendly, functional language
#114Earlier quoted context omitted.
I've been on the F# website for 5 minutes now looking through damn near every page and I cannot find a single page that shows me a simple example program or the syntax at all. Everything is hidden behind some kind of "let's get started!" wizard. https://dotnet.microsoft.com/en-us/learn/languages/fsharp-he...
Oh yeah. A key hindrance of F# is that MS treats it like a side project even though it's probably their secret weapon, and a lot of the adopters are dotnet coders who already know the basics so the on-boarding is less than ideal. https://fsharp.org/ is the best place to actually start, although i'm guessing you did and went to the hello world which leads back to ms's nightmares. https://fsharpforfunandprofit.com/ is…
fsharp.org is actually the offender. lots of links to basically nothing and quite a few of them are a dead end 404.
Re: Roc – A fast, friendly, functional language
#115For those out of the loop, Roc was spearheaded by Richard Feldman, who made major contributions to Elm. Feldman is such a charming guy! I highly recommend checking out his podcast Software Unscripted and watching his many talks on YouTube. The recent SU episode with Brian Carroll talking about WASM in Roc was a great listen. Roc also has an active community on zulip, so consider stopping by :) [1] https://twitter.com…
What happened to Elm by the way?
Elm is still delightful to use!
[1] https://taylor.town/elm-2023
Evan also announced some stuff about Elm and Postgres at Strange Loop earlier this year, so I expect another wave of movement soon
Re: Roc – A fast, friendly, functional language
#116Earlier quoted context omitted.
Glad you've been enjoying Software Unscripted, thank you for the kind words! > 1. Whether they'll support macros, The plan is not to support macros. A major reason is that macros tend to conflict with editor tooling, and I definitely have big plans for Roc's editor tooling! > 2. Whether their decision to build a whole new IDE will take away from the work that will go into an LSP (it will take a lot to pry away neovim…
> The plan is not to support macros. A major reason is that macros tend to conflict with editor tooling, and I definitely have big plans for Roc's editor tooling! I disagree! I've been working on a macro-heavy Rust project with both proc and declarative macros and the tooling makes them better. I'll add that there is immense value in turning repetitive code into "spreadsheet" style tables of data as well as being abl…
A common example of a tooling problem I've run into with Rust macros is that if I use a string interpolation macro (e.g. in an argument to println!, format!, or dbg!) a lot of VS Code tooling that works outside of macros stops working.
For example, I can't use normal context menu things on an interpolated variable name, like Go To Definition or Refactor. Similarly, if I do a semantic rename of a variable used in interpolation, it doesn't get renamed. Things like this.
Maybe these are solvable problems, but we're talking about widely used macros that have been in the standard library for many years, and even those don't have basic support for normal operations that Just Work in a non-macro context, in one of the most popular Rust editors!
Re: Roc – A fast, friendly, functional language
#117Earlier quoted context omitted.
> 1. The typesystem will be sound, ML-like, and so simple that any code that doesn't interact with external data will not need _any_ type annotations. I've tried using languages with this promise, such as Haskell, and also spent a lot of time with TypeScript, which makes a different set of tradeoffs, and I feel like I've spent enough time on both to know this is the wrong tradeoff to make. It sounds flashy to be able…
Rust takes the "at least annotate all your function signatures" approach as well. It's essential for making borrow-checking tractable (for both the compiler and the programmer).
Rust has the "you must annotate your functions signatures, because there is no global type inference possible" approach.
Re: Roc – A fast, friendly, functional language
#118No real thoughts on the language yet, other than looks interesting and modern. But, that website has one of the smoothest on boarding experience I've ever seen for a new language. From the inline REPL (with built in tutorial), to the code definition section, its insanely practical. Every new (& old) language should have a website and onboarding experience like this one.
One thing I had to hunt for was what the backslash means in the first examples. Especially as it seems to be used for both string interpolation and function definition.
But other than that great to have a quite good idea of the language in just a few seconds.
Re: Roc – A fast, friendly, functional language
#119I'm super keen to see how Roc pans out, because it sits at an (IMO) riveting spot in the space of PL design tradeoffs: 1. The typesystem will be sound, ML-like, and so simple that any code that doesn't interact with external data will not need _any_ type annotations. 2. An aim to make it the fastest managed compiled lang around (faster than golang). 3. Functional. 4. A focus on fast compile times from the beginning (…
An aim to make it the fastest managed compiled lang around (faster than golang).
I find this an interesting perspective: That Golang is a compiled managed language. This is certainly correct. I don't see this being expressed to often, however.
Re: Roc – A fast, friendly, functional language
#120Earlier quoted context omitted.
I glanced at the example code and it looked like it allowed side effects, but maybe I was wrong. I haven't had much time to mess with it and seemed to be able to hard crash the repl doing some testing so it's something i'll have to look at later.
Well, yes, if there are no type annotations because all types are inferred, you don't see the effect "types". https://www.roc-lang.org/tutorial#tasks
Then to my limited understanding that's less "pure" than haskell isn't it, which doesn't allow side effects and thus forces monads?