Live data from Hacker News

Roc – A fast, friendly, functional language

roc-lang.org

131–140 of 180 posts

Re: Roc – A fast, friendly, functional language

#131
post #98

I'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…

I think a general 'explicit > implicit' priority is good enough to cover most cases - a written signature takes precedence over an inferred one. The compiler can also simply emit errors at both sites and let the writer figure it out.

I usually think of writing explicit type annotations as 'pinning' the type in situations where things are inferred/generic by default.

Re: Roc – A fast, friendly, functional language

#132
post #98

Earlier 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…

Oh I totally agree that it's a good idea to annotate top-level functions even if you don't have to, and better compiler error messages is one of the benefits of doing that. Personally I basically always choose to annotate them except in the very specific situation of writing beginner introductory materials, when it's not a given that the reader actually knows how to read the annotations yet. One of the practical bene…

> Personally I basically always choose to annotate them except in the very specific situation of writing beginner introductory materials, when it's not a given that the reader actually knows how to read the annotations yet.

Having just gone through your tutorial (albeit not yet with a computer in hand, that's the next step), might I suggest putting those annotations in anyway? I suspect most of the people reading the tutorial will already be programmers, and one of the most useful things I've found when reading tutorials and guides is when the code examples look as much like real code as possible. When I'm reading that initial documentation, I'm not just trying to figure out what's different about this language from other languages, but I also want a sense of what it looks like to actually read and write idiomatic code in that language - what sort of formatting conventions are there, what do variable or type names typically look like, are there any common idioms, etc. Ultimately, my goal is to get up to speed and begin writing productive code as quickly as possible, so seeing type annotations everywhere is a sign to me that type annotations are good practice and something to get used to.

In general, I found the tutorial a bit too aimed towards someone learning their first programming language, which is a demographic that I suspect are unlikely to be using Roc any time soon! Even if they are a demographic you're targeting, I wonder if they'd be better served by a separate explicit "Roc as a first programming language" document that goes through the basics. Then in the main document, do some repl stuff at the beginning, but move quickly on to what regular development work might look like - starting a new project, writing functions with types, using tasks/effects, adding tests, dependencies, etc.

With all that criticism out of the way (sorry!) I do want to say that I love pretty much everything that I've seen so far, especially the focus on practical usage. It's great to see an example CLI and an example web server right on the home page - I feel like these are often left as complete afterthoughts for these sorts of languages, but they're the sort of real-world programs that dominate software in the industry.

I'm also really excited to have a play around with the effects/tasks system. It looks really powerful, but not too complicated to actually use as a base abstraction.

And I agree that having powerful type interface can be a great tool, even if you supplement it with type annotations for the sake of explicitness. Is there an explicit type hole mechanism as well, for getting the compiler to spit out the types it expects?

Re: Roc – A fast, friendly, functional language

#133
post #78
post #34

Earlier quoted context omitted.

All languages have some amount of historical baggage, but I'm not sure what you're referring to here. If anything, Haskell gets a lot of eyerolls for its slow moving pace and for trying to build a language from mathematical first principles. It's not perfect (eg.: Monad was not designed to be a special case of Applicative in the beginning, I believe) but it's better at "avoiding baggage" than many other languages I k…

Haskell is a wonderful language, but I don’t think you can claim it’s baggage free. It’s certainly accumulated it’s fair share of technical debt (more in the standard library than the core language to be fair). The endless proliferation of often complex and hard to understand extensions also certainly raises the bar for beginners.

> I don’t think you can claim it’s baggage free.

Did I?

Re: Roc – A fast, friendly, functional language

#134
post #9

If you are interested, «why yet another programming language?». The unique selling point of Roc is clever optimization to convert purely functional source code to deep-imperative fast machine code, while keeping all the correctness of functional algorithms. See this video of Richard Feldman for details — «Outperforming Imperative with Pure Functional Languages»: https://www.youtube.com/watch?v=vzfy4EKwG_Y Among those…

> - static reference counting (no GC, like in Rust, but with no borrowing and borrow problems);

Does this mean that it's somewhat equivalent to Rust with everything behind a `Rc` or `Arc`?

Re: Roc – A fast, friendly, functional language

#135
I'm super excited to see Roc up on HN.

I like the 'be fast' and 'be haskell like' approach.

I see you have an Earthfile in the repo. Let me know if you have any Earthly feedback or if I can help with the build in any way, @rtfeldman.

( We've been working on making Earthly faster for Rust builds by using cache mounts. )

Re: Roc – A fast, friendly, functional language

#136
post #9

If you are interested, «why yet another programming language?». The unique selling point of Roc is clever optimization to convert purely functional source code to deep-imperative fast machine code, while keeping all the correctness of functional algorithms. See this video of Richard Feldman for details — «Outperforming Imperative with Pure Functional Languages»: https://www.youtube.com/watch?v=vzfy4EKwG_Y Among those…

That sounds a lot like Koka. Is there any relationship?

See https://news.ycombinator.com/item?id=38350940

Re: Roc – A fast, friendly, functional language

#137

Earlier quoted context omitted.

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

The talk is at https://m.youtube.com/watch?v=XZ3w_jec1v8

I also recommend watching it, though the conclusion I came away with is that Evan is kind of in a "next steps" crisis.

Re: Roc – A fast, friendly, functional language

#139

I'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 (…

Seems to be a language equivalent to a subset of strict Haskell.

There doesn't seem to be any particularly compelling reason to use it, and note that, unless they can use libraries from an existing language, there needs to be a really MAJOR reason to use a new language to compensate the lack of libraries.

Re: Roc – A fast, friendly, functional language

#140
post #16

Earlier quoted context omitted.

Not really, no. Like Elm, it strips away practically everything that wasn't already in 1970s-era ML. It's much closer to a trimmed-down Ocaml than it is to Haskell.

Some in the ML community think a simpler language has advantages over a more expressive one, in some cases. For example: https://github.com/fsharp/fslang-suggestions/issues/243#issu...

Not just the ML community. Go's simplicity is often derided, but I think the best in class tooling (dev tooling like gopls, golangci-lint, deployment tooling like ServiceWeaver, Goreleasor, etc) and easy understandability more than make up for "what yuu can't do"
Post reply on HN