Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Roc – A fast, friendly, functional language

roc-lang.org

Post reply on HN
Print view View original

121–130 of 180 posts

Re: Roc – A fast, friendly, functional language

#121

Post by rtfeldman »

johnfn wrote: post #98
davidatbu wrote: post #80

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…

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 benefits of having full inference is that these signatures can be inferred and then correctly generated by an editor. Like I can write the implementation of my function, and then tell my editor to generate a type annotation, and it can always generate a correct annotation.

That saves me time whenever I'm writing the implementation first (I often write the annotation first, but not always), even if I end up wanting to massage the generated annotation stylistically. And unlike having Copilot generate an annotation, the type inference system knows the actual correct type and doesn't hallucinate.

To me, the main benefits of type inference at the top level are that they offer beginners a more gradual introduction to the type system, and that they offer experts a way to save time through tooling.

Re: Roc – A fast, friendly, functional language

#122

Post by weatherlight »

satvikpendem wrote: post #86
weatherlight wrote: post #74

Earlier quoted context omitted.

> other options that don't have such history Roc isn't Elm. RF is one person in that community, and he said something he regretted 5 years ago and has since not repeated that mistake. Do you know the moral dealings of every developer of every piece of technology you use? When it comes to Roc and It's community..ask yourself. “Am I sure that what I am going to say is true?” “Is what I'm going to say a good thing?”, an…

It's not about moral dealings, it's about whether I can trust the creators to not mess up a second time if they had already messed up once. We were shipping Elm in production and we moved away because any issues that were brought up that we wanted to see solved were swept away. Eventually it wasn't worth keeping the Elm codebase around. So, why should I trust one of the same people again? We already learned an expens…

So RF being questionably rude in a PR comment caused you company to drop apiece of technology?

Re: Roc – A fast, friendly, functional language

#123

Post by wibblewobble125 »

rtfeldman wrote: post #18
satvikpendem wrote: post #13

I don't know, after having used Elm and seeing the community accused of "hostile attacks" by one of the main contributors (who is the creator of Roc now) [0], I don't feel that it's worth my time to put into learning it, even if it is objectively good; I simply cannot know what the creators will do (or refuse to do, in the case of Elm) in the future, especially in a BDFL governance paradigm. This was in fact why I st…

Wow, this is depressing to read. :( 5 years ago I was upset and posted a comment that was unfairly harsh to another commenter. I apologized at the time, and I meant it. I definitely should not have made the harsh comment that I did. It was wrong. There's no excuse for my having written it. There are a lot of people working on Roc other than me. I'm not even the top committer anymore. [0] I hope you can find it in you…

As a small datapoint, I brought up Roc at work last year and a colleague said “it looked interesting but it’s the guy from Elm isn’t it?” and brought up this.

As a manager, I empathize with the frustration you were feeling. Steering a team or a community towards a vision is very hard. Just when you think you’re getting somewhere, someone does the exact opposite and mixes people up. It’s easy to lose patience. I’ve made similar mistakes on popular projects and was fortunate enough that no one publicized them. I was allowed to learn from my mistakes without being punished for it.

I don’t have any advice on this. It’ll probably turn out fine.

Re: Roc – A fast, friendly, functional language

#124

Post by whizzter »

azangru wrote: post #101
johnfn wrote: 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…

> The TS approach of "please at least annotate all your function signatures" The whole signature or just the parameters? I thought typescript is pretty chill about inferring the return type on its own.

It usually is as long as you don't do anything recursive (and a few select polymorphic instances), I can see people getting bitten by it.

Having written inferring compilers and used C++ extensively I appreciate the workings, but I can also see people getting stuck with it.

Re: Roc – A fast, friendly, functional language

#125

Post by satvikpendem »

weatherlight wrote: post #122
satvikpendem wrote: post #86

Earlier quoted context omitted.

It's not about moral dealings, it's about whether I can trust the creators to not mess up a second time if they had already messed up once. We were shipping Elm in production and we moved away because any issues that were brought up that we wanted to see solved were swept away. Eventually it wasn't worth keeping the Elm codebase around. So, why should I trust one of the same people again? We already learned an expens…

So RF being questionably rude in a PR comment caused you company to drop apiece of technology?

One cut among many. Another was the insistence of Evan to cut out escape hatches and insist that everything be done solely through Elm. It is not just one person, the entire community was part of the problem, in one way or another. I don't think about Elm much anymore but what I do think of it does not inspire confidence at its creators' future endeavors. Of course, if people want to use it, by all means, but being burned once, not just technologically but also financially, I would not want to be burned once more.

Re: Roc – A fast, friendly, functional language

#126

Post by fuzztester »

rzwitserloot wrote: post #22
skitter wrote: post #5

Neat, looks like the website got an overhaul. I like Roc's approach of detecting errors statically but still trying to let you run the code. If a snippet is work in progress and has an unused variable, Go or Zig will refuse to compile it. Yes, an unused variable indicates a problem, which is why it's not going to pass any sensible CI setup and make its way into production, but that doesn't mean I should be disallowed…

Many java editors (notably, eclipse) work the same way, _if_ you configure them to do so_: Just run it, don't worry about the compilation errors. If the code never hits that segment (in java, if there's a syntactical error in source code, that entire class cannot be used, but if it's a semantic error (e.g. a reference to a function that doesn't exist, which is syntactically perfectly valid, that's a semantic error),…

>If you hit a tainted area the debugger kicks in, freezes the process, and breakpoints on the spot. You can then fix it if you want and continue, or inspect the stack and state of e.g. local vars and learn something.

>What I find surprising is how few programmers I talk to are aware of this, let alone use it. I find it a significant productivity boost.

Forward to the past, as often is the case.

See:

https://news.ycombinator.com/item?id=37841588

and its parent and child comment.

Re: Roc – A fast, friendly, functional language

#127

Post by whizzter »

Eji1700 wrote: post #120
ReleaseCandidat wrote: post #95

Earlier quoted context omitted.

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?

Honestly it looks like basically the same as getline/putStrLen from the tutorial(1) in the link below, just not written in an intentionally obtuse language.

Considering how much more approachable this Roc documentation/naming is, I'm wondering if it isn't so that the people writing Wikipedia's math pages are probably the same people that are drawn to and writes Haskell/monad "tutorials".

1: http://learnyouahaskell.com/input-and-output

Re: Roc – A fast, friendly, functional language

#128

Post by itishappy »

jampekka wrote: post #118
drannex wrote: post #6

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

It's both string interpolation and (anonymous) function definition.

    # Function Definition:
    addAndStringify = \num1, num2 ->
        Num.toStr (num1 + num2)

    # String Interpolation:
    "\(greeting) there, \(audience)!"
    # desugars to
    Str.concat greeting (Str.concat " there, " (Str.concat audience "!"))
https://www.roc-lang.org/tutorial

Re: Roc – A fast, friendly, functional language

#130

Post by packetlost »

rtfeldman wrote: post #116
packetlost wrote: post #112

Earlier quoted context omitted.

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

> 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

I imagine this isn't that hard of a problem to solve (though maybe relying on VSCode to handle renames is part of the issue), but low-enough on the annoyance scale that nobody cares enough to implement it. I'm not going to argue there aren't annoyances with macros and that they're harder for tooling to deal with, but I don't think that's a sufficient justification to not have them at all IMO.

Post reply on HN