Roc isn’t even at a numbered version yet (i.e. it’s pre v0.0.1), so it’s still in the experimentation phase. The biggest area of interest at the moment seems to be backend web development, but there’s also discussion around gamedev and scientific computing uses.
EDIT: I know you want to push your own editor for ROC, but are there any plans to provide a TreeSitter grammar and an LSP, so we can use Helix/Nvim/Emacs/… ?
Short answer is that the editor project has been deprioritized a lot (e.g. I don’t expect any work to be done on it in 2024) because we realized there’s a way to build the editor plugin ecosystem we want to build in a way that works across multiple editors!
An initial tree-sitter grammar was created a few days ago, and there is a slightly flakey language server that integrates with one of the VSCode extensions. I think plans for the Roc editor have changed, but I haven’t kept up with what the new plan is.
Elm 0.19 nuked any good thoughts I had towards the language. Limiting native modules to a small group of people was a bad design decision, and the lack of leadership has imo doomed the language. elm-janitor is a project that exists to cleanup the mess, and they link a useful but sad spreadsheet of all the fixes that have yet to be merged.
If I were to stick to a functional language today, I would bet on Roc succeeding where Elm couldn’t.
I think ReScript has pretty much taken that niche already. It did what Elm didn’t–provide a pragmatic, interoperable integration with the rest of the JS ecosystem while also providing type safety and fast compiles.
mm this does look like a proper replacement, whereas my Roc evangelism is probably premature. my first question would be how it differs from reason ml which also fills the functional-web niche
ReScript is a continuation of the ReasonML functional-web effort. It split off from the ‘ReasonML’ branding to create a more integrated, turnkey experience for typed functional web dev.
This may sound nit-picky or unreasonable, but the immediate blocker for me adopting ReScript is its take on Option/undefined/null.
I actually do use undefined and null to mean semantically different things in my JavaScipt/TypeScript code. For example, if I’m sending a POST request to my backend API, it will treat a missing field (undefined) as unset and needing the default value (if it is intended to be optional), and it will treat a present null to mean that the client is explicitly denoting “emptiness” for the value and it will NOT be overwritten with a default value.
Likewise, in languages with a generic Option type (Swift, Rust, Kotlin-when-I-write-it), I do sometimes represent the above semantics similarly by having an Option<Option<T>> (or Option<T?> in Kotlin) for an “optional nullable” value.
I realize that ReScript has escape hatches for these things, but I feel like “escape hatches” are for uncommon situations; I don’t want to have these “escape hatches” all over my code and have to fight against the grain of the language.
As much as I loathe TypeScript, I feel like I’m stuck with it.
Right, I know. It’s just that the standard library functions all use option<'a>, so I worry about needing to do a bunch of fiddling between three kinds of “maybe present” types instead of the usual two. Maybe in practice it isn’t bad, but I’ve dug myself into plenty of holes before while trying to go against the grain of the language I was using.
I don’t see any big problems, you just define your form fields with strong types like myField: option<string> and convert the weaker-typed values received over the network into strongly-typed internal values with checks and converter functions. It’s conceptually very similar to TypeScript except it doesn’t suffer from the ‘wrapping’ problem because the option type has special compiler support.
I remember really liking Roc when I looked at it a couple of years ago. Is there a killer app or niche yet for the language?
Roc isn’t even at a numbered version yet (i.e. it’s pre v0.0.1), so it’s still in the experimentation phase. The biggest area of interest at the moment seems to be backend web development, but there’s also discussion around gamedev and scientific computing uses.
I’ve been waiting for this for so long. Thanks!
EDIT: I know you want to push your own editor for ROC, but are there any plans to provide a TreeSitter grammar and an LSP, so we can use Helix/Nvim/Emacs/… ?
Short answer is that the editor project has been deprioritized a lot (e.g. I don’t expect any work to be done on it in 2024) because we realized there’s a way to build the editor plugin ecosystem we want to build in a way that works across multiple editors!
There already is a preliminary language server, and there are instructions in the VS Code extension for how to get it set up: https://github.com/ivan-demchenko/roc-vscode-unofficial#configuring-language-server
An initial tree-sitter grammar was created a few days ago, and there is a slightly flakey language server that integrates with one of the VSCode extensions. I think plans for the Roc editor have changed, but I haven’t kept up with what the new plan is.
Elm 0.19 nuked any good thoughts I had towards the language. Limiting native modules to a small group of people was a bad design decision, and the lack of leadership has imo doomed the language. elm-janitor is a project that exists to cleanup the mess, and they link a useful but sad spreadsheet of all the fixes that have yet to be merged.
If I were to stick to a functional language today, I would bet on Roc succeeding where Elm couldn’t.
I think ReScript has pretty much taken that niche already. It did what Elm didn’t–provide a pragmatic, interoperable integration with the rest of the JS ecosystem while also providing type safety and fast compiles.
mm this does look like a proper replacement, whereas my Roc evangelism is probably premature. my first question would be how it differs from reason ml which also fills the functional-web niche
My understanding is that ReScript is essentially a rebranding of ReasonML which has mostly been abandoned.
ReScript is a continuation of the ReasonML functional-web effort. It split off from the ‘ReasonML’ branding to create a more integrated, turnkey experience for typed functional web dev.
This may sound nit-picky or unreasonable, but the immediate blocker for me adopting ReScript is its take on
Option/undefined/null.I actually do use
undefinedandnullto mean semantically different things in my JavaScipt/TypeScript code. For example, if I’m sending a POST request to my backend API, it will treat a missing field (undefined) as unset and needing the default value (if it is intended to be optional), and it will treat a presentnullto mean that the client is explicitly denoting “emptiness” for the value and it will NOT be overwritten with a default value.Likewise, in languages with a generic Option type (Swift, Rust, Kotlin-when-I-write-it), I do sometimes represent the above semantics similarly by having an
Option<Option<T>>(orOption<T?>in Kotlin) for an “optional nullable” value.I realize that ReScript has escape hatches for these things, but I feel like “escape hatches” are for uncommon situations; I don’t want to have these “escape hatches” all over my code and have to fight against the grain of the language.
As much as I loathe TypeScript, I feel like I’m stuck with it.
ReScript can deal with
nullandundefinedseparately using its provided APIs:Right, I know. It’s just that the standard library functions all use
option<'a>, so I worry about needing to do a bunch of fiddling between three kinds of “maybe present” types instead of the usual two. Maybe in practice it isn’t bad, but I’ve dug myself into plenty of holes before while trying to go against the grain of the language I was using.I don’t see any big problems, you just define your form fields with strong types like
myField: option<string>and convert the weaker-typed values received over the network into strongly-typed internal values with checks and converter functions. It’s conceptually very similar to TypeScript except it doesn’t suffer from the ‘wrapping’ problem because the option type has special compiler support.Wow that spreadsheet is really depressing.