Richard Feldman is so smart I really like his approach and what's he's trying to do with Roc Lang. It feels like that's what we should've had from the beginning ahah. But it's so hard now to convince and make people adopt a new language, I think.
Great discussion. I love Elm and amount of stuff I learn from Richard I feel I own him 10% of my salary every month, (not only about Elm but general software dev practices.)
Great language, wish it considered implementing macros though, because that is certainly a powerful feature in Elixir, as long as its use is limited (which it usually is, from what I can tell)
what would you use the macros for? I can get behind some comptime code generation (shout out for c#!), but I never liked macros. Even with Rust, macros just patch stuff what "should be in the language" (like async/await)
@@Qrzychu92 comptime is just a different paradigm with a slightly different focus. it makes sense to prefer one after another but it's clear that langs like c# java go move tons of things to the runtime simply because they don't have a comptime/macro implementation. a lang like rust or cpp or zig simply can't do that so they chose to go with this route by having another lang on top of the original lang. if you have a nice feature like this, it makes sense to use it in the standard library. it however does not make sense to not generalize the problem and not make the feature exposed to the public as you can't possibly know beforehand how people are going to want to use it. it makes no sense for rust maintainers to maintain a sql dsl when the users can just do that themselves.
@@biskitpagla I am fully aware of that :) I was responding to a comment about Elixir needing macros. Rust macros are fine I guess. But C/C++ preprocessor #define is just evil. It's just text replacement, confusing IDEs, with 0 limits (like #define true false is fine). Since Elixir is high level, what would macros do? Redefine true as false, or allow to add await? Elixir doesn't need await, it has message passing. That's its whole thing. JSON or XML deserialization? That should be in the standard library, come on
It's funny to me that "language designers" often don't seem to see the parallels between designing a language and designing an application. The way Richard describes his approach around minute 17 and how he tries to prevent (syntax) feature creep is pretty much the same as good UX design prevents that from happening in an application. Languages are applications for developers, especially nowadays where user-facing aspects (like editor features and performance and syntax) become increasingly important factors for devs to pick a language.
Gleam leaves little reason to adopt Roc , this lang will be DoA unless they narrow the scope. Everybody stroking to “platforms” have no idea how deployments are handled in industry-what’s next, embedded Ansible?
Plugin support is there, and there are plenty extensions available. AI is marketing, there are plenty of things to like about zed beside AI. In my experience it is better and more stable than lapce, with more plugins available.
I can get llama 3.1 8B to run at 72 words per minute through Ollama (accelerated by me AMD video card). Surely that would be way better than using a cloud API.
Richard Feldman is so smart I really like his approach and what's he's trying to do with Roc Lang. It feels like that's what we should've had from the beginning ahah.
But it's so hard now to convince and make people adopt a new language, I think.
Great discussion. I love Elm and amount of stuff I learn from Richard I feel I own him 10% of my salary every month, (not only about Elm but general software dev practices.)
roc-lang
You don't have to put on the debug light
Those bugs are over
You don't have side-effects so don't debug into the night
took me a while to get it XD
I though it was "Roclang" without a "k"
It is
Corrected 🤞
@@devtoolsfm also the chapter names say 'rock' too!
Also the description
@@TheFwip That's where the chapter names come from, pretty sure
Damn it, Richard. Why you distract me with awesome new language!
Great language, wish it considered implementing macros though, because that is certainly a powerful feature in Elixir, as long as its use is limited (which it usually is, from what I can tell)
what would you use the macros for? I can get behind some comptime code generation (shout out for c#!), but I never liked macros. Even with Rust, macros just patch stuff what "should be in the language" (like async/await)
@@Qrzychu92 comptime is just a different paradigm with a slightly different focus. it makes sense to prefer one after another but it's clear that langs like c# java go move tons of things to the runtime simply because they don't have a comptime/macro implementation. a lang like rust or cpp or zig simply can't do that so they chose to go with this route by having another lang on top of the original lang. if you have a nice feature like this, it makes sense to use it in the standard library. it however does not make sense to not generalize the problem and not make the feature exposed to the public as you can't possibly know beforehand how people are going to want to use it. it makes no sense for rust maintainers to maintain a sql dsl when the users can just do that themselves.
@@biskitpagla I am fully aware of that :) I was responding to a comment about Elixir needing macros.
Rust macros are fine I guess. But C/C++ preprocessor #define is just evil. It's just text replacement, confusing IDEs, with 0 limits (like #define true false is fine).
Since Elixir is high level, what would macros do? Redefine true as false, or allow to add await? Elixir doesn't need await, it has message passing. That's its whole thing.
JSON or XML deserialization? That should be in the standard library, come on
It's funny to me that "language designers" often don't seem to see the parallels between designing a language and designing an application. The way Richard describes his approach around minute 17 and how he tries to prevent (syntax) feature creep is pretty much the same as good UX design prevents that from happening in an application.
Languages are applications for developers, especially nowadays where user-facing aspects (like editor features and performance and syntax) become increasingly important factors for devs to pick a language.
What makes you think that "language designers don't seem to see the parallels"?
Gleam leaves little reason to adopt Roc , this lang will be DoA unless they narrow the scope. Everybody stroking to “platforms” have no idea how deployments are handled in industry-what’s next, embedded Ansible?
Zed is a great example on how to focus on the features that matter the less. They should build plugin support, that is the most important thing
Plugin support is there, and there are plenty extensions available. AI is marketing, there are plenty of things to like about zed beside AI. In my experience it is better and more stable than lapce, with more plugins available.
@@munchymanjaro9070 It also has a way better name than the ridiculously-poorly-named "lapce", something which unfortunately matters.
I can get llama 3.1 8B to run at 72 words per minute through Ollama (accelerated by me AMD video card). Surely that would be way better than using a cloud API.
it’s way faster on M1/2/3 Mac
Also, check out the new model “Reflection,” it is the new king!
You need a video card though
Richard Feldman is a snitch
?