วีดีโอ

That true, everytime I hear or see Richard talk I end up in better mood, convinced that tomorrow will be better 😀

Excellent ! Thanks for sharing this.

Great talk. Thank you!

how does this compare to rich hickey clojure?

Great talk! Lots to think about. Your point on sugar vs "primitive" is so great. I think it captures the essence of a lot of language design. :-)

Roc rocks! I cannot wait more for the release of this new PI approach pushing the Task builtin to the low level space. It's a good move. I wish there will be more concern about the Mach-O linkage. Richard (like Andrew Kelley) is such good speaker. He's right about the backpassing syntax, it looks smart but totally unnecessary. I code in Shen/Common Lisp, Fennel/Lua & Zig these days (from Web backends to embedded systems). I can see a future for Roc in my workflow: functional and pragmatic. IMHO, a good generic programming language should have 0 or less keywords 🙂and Prolog is the king, there... Roc has a way of proposing a KISS way of coding with very few keywords while still experimenting its own paradigm. It's a refreshing!

"The Functional Purity Inference Plan" doesn't sound like computer science, but more like a socio-religious experiment.

Amazing! I’m going to try out Roc now. And I’m actually tempted to start writing my CLI programs in Roc as well.

🎯 Key points for quick navigation: 01:25 *📖 Pure Function Definition: A pure function always returns the same output for the same input and has no observable side effects.* 02:00 *🔍 Lookup Table Analogy: Pure functions can be thought of as lookup tables that map inputs to outputs without altering state.* 02:53 *🧩 Elm Ecosystem: In a purely functional language like Elm, functions are consistently pure, reducing ambiguity and simplifying debugging.* 04:18 *🚀 Rock Language Goals: Rock focuses on being fast, friendly, and purely functional, aiming for rapid compile times and efficient performance.* 05:03 *⚡ Effects vs. Side Effects: Purely functional languages handle effects like I/O through values representing those effects, avoiding side effects.* 06:13 *🧱 Pure and Effectful Code: Even in functional languages, codebases mix pure functions and effectful code to handle real-world tasks.* 07:34 *🛠️ Imperative Languages Adopting FP: Languages like Rust, Kotlin, Swift, and TypeScript support functional styles but remain fundamentally imperative.* 08:42 *🧭 Rust’s FP Support: Rust supports functional programming concepts, but its core style remains imperative.* 09:19 *🔧 TypeScript FP Adoption: TypeScript is commonly used in a functional style, with many developers preferring FP-first approaches.* 10:04 *✅ TypeScript Purity Assurance: Pure functions in TypeScript rely on developers manually verifying purity; type signatures don’t enforce it.* 13:14 *🖨️ Imperative Simplicity: Some tasks, like printing sequences, are naturally suited to imperative code for clarity and efficiency.* 15:00 *⚖️ Efficiency Considerations: In certain cases, imperative code is more efficient, avoiding redundant loops and computations.* 16:00 *🤝 Fit for Purpose: Imperative programming can be the best approach for specific problems, even for developers who prefer functional programming.* 16:43 *🔄 Recursion vs. Loops: In languages without for loops, recursion can replace them, but the resulting code may not be clearer or easier to understand.* 17:46 *❗ Effectful Code: In Rock, side effects are represented using tasks, but this can complicate code readability.* 19:28 *🆕 Imperative Support: Rock is introducing imperative-style syntax (e.g., `var`, `for` loops) while maintaining functional purity principles.* 20:18 *📝 Syntax Similarity: Rock's imperative syntax closely resembles TypeScript’s, with slight differences like `do` blocks and no semicolons.* 21:45 *🔍 Pure vs. Effectful Functions: Rock will differentiate pure functions (thin arrows) and effectful functions (thick arrows) in type signatures.* 22:59 *🚫 Compiler Enforcement: Pure functions in Rock cannot call effectful functions, ensuring purity is preserved.* 23:25 *🔄 Reassignments with `var`: The `var` keyword in Rock allows reassigning names within functions, but not mutating values.* 24:56 *🛡️ Immutable Guarantees: Even with `var`, Rock guarantees that values passed into functions cannot be mutated externally.* 26:28 *📊 Information-Rich Code: Rock’s type signatures and naming conventions (e.g., `!` for effectful functions) provide clear insights into function behavior.* 27:44 *⚠️ Exclamation Naming: Functions with side effects end with `!`, making effectful operations easy to identify at a glance.* 30:17 *🔄 `var` Naming Convention: Variables that can be reassigned end with an underscore, helping distinguish them from constants.* 32:20 *🔀 Code Portability: Pure functions allow flexible code reordering, whereas reassignments limit this flexibility.* 32:54 *⚠️ Portability Warnings: The underscore convention warns developers when code is not easily portable due to variable reassignment.* 33:49 *🔍 Quick Inference: Even without the function name or type signature, developers can infer purity and portability by glancing at code conventions like exclamation points and underscores.* 36:45 *🕵️‍♂️ Debugging Clues: The exclamation point convention acts as a clue to potential gotchas in code, aiding in debugging and understanding.* 37:46 *💡 Information Richness: Minimal syntax additions, like an exclamation point, can provide valuable insights into function behavior without cluttering the code.* 39:13 *📄 Thick Arrow Utility: The thick arrow explicitly indicates effectful functions, making type discussions clearer, especially in API design or REPL scenarios.* 43:19 *🛠️ Preventing Mistakes: The `var` keyword prevents accidental variable conflicts when copying and pasting code, reducing potential bugs.* 45:01 *✅ Purity with `var`: Using `var` inside a function doesn’t affect its purity; purity depends only on input-output consistency.* 46:32 *🔄 Imperative Flexibility: Rock aims to support an imperative style when it suits the problem, without sacrificing functional principles.* 49:33 *🚀 Ease into Functional Programming: Beginners can start writing imperative-style code in Rock and gradually adopt functional idioms over time.* 50:23 *🛠️ Rust’s `clone` Analogy: Just like Rust's `clone` helps beginners bypass complexity, Rock’s imperative support provides an accessible learning path.* 51:34 *🧗 Smoother Learning Curve: Rock aims to avoid the steep learning curve of recursion by providing simple imperative constructs like loops and variable reassignment.* 52:13 *📝 Simplified Syntax: Rock's new syntax for handling effects is clearer and avoids complex task chaining, making code more readable.* 52:48 *🔄 Backpassing Challenges: Earlier designs like backpassing confused beginners, prompting a shift to simpler syntax for handling effects.* 54:20 *🧩 Alternative Designs: Gleam and Haskell’s approaches to chaining tasks were considered but found to be too complex for beginners.* 55:54 *⚠️ Clearer Error Messages: Rock’s new design promises simpler and clearer error messages by avoiding complex desugaring.* 56:37 *❌ Limitations of Chaining: Chaining syntax struggles with conditional logic, making straightforward imperative code more practical for such cases.* 58:52 *⚡ Performance Considerations: Task-based handling introduces performance overhead; new designs aim to support high-performance concurrency similar to Go.* 01:00:47 *🔍 Minimalistic Approach: Rock aims for a simple and minimal system with binary algebraic effects, focusing on purity and effectfulness.* 01:02:57 *📦 New Primitives: Although adding new primitives like `var` and effectful arrows, the overall goal is to make Rock easier for beginners while maintaining simplicity.* 01:04:27 *✅ Compiler Enforcements: Rock’s compiler will enforce purity, effectfulness, and variable conventions to maintain code clarity and consistency.* 01:05:21 *💬 Considering Break and Continue: The team is open to adding `break` and `continue` statements in the future but sees it as non-critical for now.* 01:05:41 *📝 Rock’s New Identity: Rock is transitioning from a purely functional language to one with purity inference, maintaining a functional core.* 01:07:10 *🔒 Var in Closures: Vars captured in closures cannot be mutated. The team may enforce this strictly or allow immutable snapshots for convenience.* 01:09:27 *🌐 Platforms in Rock: Rock applications are built on a single platform that interfaces with non-Rock languages, typically via Rust, Zig, or CFFI.* 01:10:57 *🔄 Single Platform Rule: Each Rock application must use exactly one platform; combining multiple platforms is not supported.* 01:12:33 *⚠️ Effectful Functions Must Have Effects: Rock’s compiler warns if a function is marked as effectful but does not perform any side effects.* 01:14:18 *🔍 Reading Code Clarity: Richard prioritizes code readability and prefers imperative style when recursion or functional constructs complicate comprehension.* 01:19:52 *🎓 Target Audience: Rock’s design considerations focus on programmers familiar with coding, not absolute beginners.* 01:21:30 *⚖️ Trade-Offs in Design: The team acknowledges design trade-offs, particularly around error handling and early returns, settling on a `try` keyword inspired by Zig.* 01:22:40 *🧪 Experimentation Over User Testing: Rock is in a pre-1.0 phase, so changes are made through iterations and experimentation rather than formal user testing.* 01:23:05 *⚠️ Expect Change: Because Rock is still in development with nightly builds, users should expect frequent changes to the language.* 01:23:38 *🔄 Major Yet Subtle Change: The shift to purity inference is a significant change, though much of the current code will look similar, as the exclamation point operator transitions to a naming convention.* 01:24:43 *🚨 CI Failure on Warnings: Compiler warnings won’t prevent local builds but will exit with a non-zero code, causing CI pipelines to fail automatically if warnings are present.* 01:25:16 *🎉 Community Enthusiasm: The community appreciates Rock’s strategy of adopting imperative features while maintaining functional programming principles.* Made with HARPA AI

Love the introduction of the for loop with careful thinking behind it! Excited to see where it goes :)

Definitely agree on that line separated type def ... Can't even really put it into words, other than it's an elegant and usefully elegant way of laying out code, ensuring readability and clarity of intent. I've been programming for 35+ years and I find I read more then I write now, so it's very important to me, and at least we now don't have to worry about every byte of RAM saved in a compilation pass! Good stuff Sir! Ed: I know I'm cart before horse here but was just wondering, if its a principle to make it difficult for someone to 'accidently' de-pure the function, you could perhaps: abs : F64 --> F64 by n abs = n if n >= 0 else -n this is as close as I can put an approach I'm using in a DSL to abs ... so, the type obviously enforces parameter count and type, and as a convenience can set you up with a known state too, 'by way of n'. We know it's returning so I can give it a likelihood guess that n's gonna be positive more often and then you've also got a nice chance of short circuiting extraneous code. To be honest though, my DSL is not particularly Functional as I'm simming old Mainframe code!! But, I do like to try for elegant but practical ... I'm the poor fool who's got to maintain it and wonder what I was writing 5 years ago!

Terrific presentation. Is the code for the demo game somewhere on GitHub?

Richard Feldman is a snitch

aaaand this is why F Hash isn't popular 😂

How often do names change? Really? A straw man leading away from the many upsides of Merkel trees for “versioning”. In actuality, I would even include the name of definitions into that Merkel tree itself.

Love to see that Roc is getting more pragmatic!

4:42 Not a big issue but I hope some day compiler will be smart enough to understand that non-empty compile-time list is never empty :)

I've literally just saw Jose Valim on ThePrimeagen show telling that he tries and tried to bring imperative while loop in functional language.

This is super clever!

great people are presenting in your group

I've been following Roc for a while now (I did the advent of code in it last year!), and I was just wondering, what was the reasoning for only using a naming convention of ending impure functions with "!" instead of requiring "!" as an operator when calling impure functions? It seems to me that it would be simpler to have it be based on the type of the function being called, similar to how "?" or "try" are often used for calling fallible functions (e.g. Zig, Rust). Was it mainly so that changing a function from pure to impure just causes warnings rather than type errors? Also, I'm a big fan of the approach of keeping a simple distinction between pure and impure functions. For a while, I was working on a compiler that supported annotating arbitrary effects (including effect-polymorphic types and functions) as a personal project, and it led to a lot of complexity that probably isn't worth it in my opinion (especially regarding type inference and compiler errors). I'm excited to see where Roc goes!

Roc is looking spectacular! 🎉 I wish Richard and friends would hurry up and get it out the door. LOL.

At 26:00, if you put another function within the printAsteriks! function that mutated totalPrinted_, wouldn't that one be unpure?

Great talk as always! I really loved the -> and => features, and using the bang (!) to unwrap the result is awesome. I’m not too sure about the var x_ = 1; x_ = x_ + 1 syntax, though. I think something more explicit would work better for mutability. Like var x = 1; x <- x + 1

LOL I was prepared to be surprised, turns out its just effectful types. Also, Julia-like in place mutation convention.

awesome :D

Cool vid! Just to say the feature attributed to Gleam at around 50mins doesn't exist in Gleam. Gleam doesn't have anything like that as we prefer to always keep it explicit.

Super talk, plus great Q&A dialogue at the end.

Man, so fun audiences :)

Great video!

Sounds like the mic is about 15 feet away from the speaker.

Lots of great ideas here. However I think this makes dependency management really difficult. For example, if you have a large function which is found to have an important bug in some old version, it seems like it would be really hard to identify the users of that code and patch the bug just for the affected cases.

I don't like type-inference. "Explicit is better than implicit". Reading other people's code in languages with type-inference can sometimes be very confusing. I see type annotations as more documentation for the reader/maintainer. If a feature makes it easier to read other people's code and harder to write your own code, then reading trumps writing and it's a good feature. and If the converse is true, it's a bad feature. "Typing [as in pressing keys on the keyboard, not type-systems] is not the bottleneck".

nice work...

Hey, great talk! I am wondering how you get the hx attributes for lucid?

Efsanesin hocam

great insights

no mutable variables == no mass adoption

THANK YOU

For those interested, I recommend Koka. Really incredible language.

If it had array programming where the old arrays were dropped after writes, I would use it

Comedy!

Would we still need Elm if we have Roc with a corresponding Web UI library?

The questions intermission ends at 49:32

I came up with this idea of storing programs in structural format aroun 2013 - originally thought its future just like you think. I later however found value in the text representation - just more structured languages, but still text. I think now that is future not this. Also learned that big-idea languages usually are not the future - they are useful experiments as full-size prototypes more often than solutions. -- But its really interesting to see something similar to what I imagined back in uni (and also talked to people about) come to exists ;-) Its also so interesting to see its "same core idea made differently" - also the distributed part is interesting and all where you went with this idea is actually pretty awsome..

“The compiler can always infer the type.” Whoa. That’s pretty cool.

P r o m o S M 👇

I believe the statement at 26:30 is incorrect about Rust. Calling `let fut = get_movies();` does not immediately fire an HTTP request. One must do `fut.await` afterwards (or just do `get_movies().await`.

Promo-SM

fantastic and easy to grasp. thank you so much!