The exposition/intro parts of these videos are exceptional in how they provide a frame of reference and also in their style of presentation. This person should definitely teach at (a very British) university.
Beautifully expressed! Everything was presented so concisely, with great insights and thoughtful topics. I wish we had more podcasts like Developer Voices!
Very interesting conversation. Yorick is clearly well-read on programming languages and I totally agree with his statement about the need for algebraic data types, they really do make a language easier to live with. However, I disagree about channels being required as a concurrency primitive. He is correct that creating memory safe mailboxes leads you down a difficult path through session types, but I think this complexity is unavoidable. This is because channels, while they can have a single well defined type, do not allow you to describe how the messages that a process expects to receive change over time, such as in a network protocol. Think about TCP, you have to establish a connection with a SYN and ACK, before you can actually start passing payload data over the connection. You can't model this in a fully type-safe way using channels. So, if you want that safety and the composability that comes with it, you're forced down the path to session types.
At 10:19, Peterse says values are heap allocated by default. Oh boy, that's a biggie! This might be a perfectly fine choice considering the target of "mid-level-ish" language that Peterse talks about but I suspect this is going to entail the same performance hit that Swift takes with its RC based approach. But still, overall this language looks great, and as promised so much more approachable than Rust. Definitely giving this a try.
Awesome interview! Looking at inko, I do think Yorick is missing a big part about syntax which is that approachable syntax does drive engagement and helps the userbase grow.
Concerning reference capabilities: Pony has six of them and some of them correspond to concepts that you’re already familiar with. It’s true that you need to figure out the capability system before you’ll be productive in the language but it’s not as complicated as some people think and the rest of the language is very similar to other languages that you already know.
Why are you writing a language, if it isn't to program in it? I have spent quite a few hours thinking up language constructs, then "test-programming" in these, writing some code with a set of assumptions for how it is supposed to work, to see if it is feasible and usable, and if it adds value, simplifying what it was meant to. Usually the "spec" will change in my head while doing this, and after a while the interest dies. Except when it doesn't, when it leads to something usable, something that meets the intent in some way. I did take a compiler class in university, which started my interest, and experimented writing an object oriented Lisp dialect, meant for driving a multiplayer text game, like LPMud, if anybody remembers the Mud games. The language exeperimentation was much more fun than creating an actual game, of course. For me building a language means creating an interpreter, not the nitty gritty of compiling to an executable. I have written three languages that have actually been used (a PDF generator, a web framework, and now an interactive shell), and they are all interpreters, because they all try to create an environment that reduces complexity, and reduces code size, leaving the heavy lifting to the underlying language (Java in my case). In this context, it makes sense with an interpreter, because the language isn't primarily about performance, nor about expressing all kinds of low level stuff anyway. The interpreter naturally inherits the garbage collect from Java. I realize others will find deep optimization interesting. Measuring the difficulties of writing a language up against the "success" of others using it, is the wrong starting point, in my opinion. If you're not writing a language for yourself, just stop. If you yourself can't use it and tailor it for a class of problems, nobody else will. If you can not document it, and explain its mechanisms, and follow up with lots of example code, then again, nobody else will do that for you.
to me it's a shame it's curly braces across the board with some minor, if notable exceptions. these new languages like Gleam, this one, and more could really do more to move things along here. Kudos to Scala 3 for making a move towards a quieter syntax. see, while it's a cliche, almost, to say, syntax does not matter, it absolutely does. it's what your eyes see, so the quieter it is, in general, the less noise it has, the better, imo.
I feel similarly, though when Pony was mentioned I checked it out and was pleasantly surprised by its syntax. Text now seems to me more like a protocol between the editor and the programming language, I've seen some of the stuff Lisp people are doing with visual programming that looks awesome as well.
@@lwinklly yup. I also liked how Coffeescript looked. and ofc Euby and so on. really love quiet syntax, the concept itself. I showed Coffeescript to a FE friend of mine who does TS/react on our team and he hated it. but it's just -- I feel like -- cause it's relatively unfamiliar to someone used to C-like syntax exclusively.
I'd love to! She's totally in my personal Hall of Fame. I did try to get her on a few months back, but couldn't get a hold of her. Maybe it's time to gently try again. 🤞
Chris, you’re so good at framing your interviews. You have interesting reasons for having them, and you provide great context.
The exposition/intro parts of these videos are exceptional in how they provide a frame of reference and also in their style of presentation. This person should definitely teach at (a very British) university.
Beautifully expressed! Everything was presented so concisely, with great insights and thoughtful topics. I wish we had more podcasts like Developer Voices!
Very interesting conversation. Yorick is clearly well-read on programming languages and I totally agree with his statement about the need for algebraic data types, they really do make a language easier to live with. However, I disagree about channels being required as a concurrency primitive.
He is correct that creating memory safe mailboxes leads you down a difficult path through session types, but I think this complexity is unavoidable. This is because channels, while they can have a single well defined type, do not allow you to describe how the messages that a process expects to receive change over time, such as in a network protocol. Think about TCP, you have to establish a connection with a SYN and ACK, before you can actually start passing payload data over the connection. You can't model this in a fully type-safe way using channels. So, if you want that safety and the composability that comes with it, you're forced down the path to session types.
At 10:19, Peterse says values are heap allocated by default. Oh boy, that's a biggie! This might be a perfectly fine choice considering the target of "mid-level-ish" language that Peterse talks about but I suspect this is going to entail the same performance hit that Swift takes with its RC based approach.
But still, overall this language looks great, and as promised so much more approachable than Rust. Definitely giving this a try.
Awesome interview! Looking at inko, I do think Yorick is missing a big part about syntax which is that approachable syntax does drive engagement and helps the userbase grow.
Inko seems like a really nice extension of Nushell-I’d love to see the async features there.
👍
Thanks! I really appreciate the support. ❤️
Concerning reference capabilities: Pony has six of them and some of them correspond to concepts that you’re already familiar with. It’s true that you need to figure out the capability system before you’ll be productive in the language but it’s not as complicated as some people think and the rest of the language is very similar to other languages that you already know.
Gleams implementation of concurrency doesn't require using dynamic or any other reduction in type guarantees.
Getting C interop is the most important thing. This would also solve TLS support.
Why are you writing a language, if it isn't to program in it?
I have spent quite a few hours thinking up language constructs, then "test-programming" in these, writing some code with a set of assumptions for how it is supposed to work, to see if it is feasible and usable, and if it adds value, simplifying what it was meant to. Usually the "spec" will change in my head while doing this, and after a while the interest dies.
Except when it doesn't, when it leads to something usable, something that meets the intent in some way.
I did take a compiler class in university, which started my interest, and experimented writing an object oriented Lisp dialect, meant for driving a multiplayer text game, like LPMud, if anybody remembers the Mud games. The language exeperimentation was much more fun than creating an actual game, of course.
For me building a language means creating an interpreter, not the nitty gritty of compiling to an executable.
I have written three languages that have actually been used (a PDF generator, a web framework, and now an interactive shell), and they are all interpreters, because they all try to create an environment that reduces complexity, and reduces code size, leaving the heavy lifting to the underlying language (Java in my case). In this context, it makes sense with an interpreter, because the language isn't primarily about performance, nor about expressing all kinds of low level stuff anyway. The interpreter naturally inherits the garbage collect from Java.
I realize others will find deep optimization interesting.
Measuring the difficulties of writing a language up against the "success" of others using it, is the wrong starting point, in my opinion. If you're not writing a language for yourself, just stop. If you yourself can't use it and tailor it for a class of problems, nobody else will. If you can not document it, and explain its mechanisms, and follow up with lots of example code, then again, nobody else will do that for you.
cool episode :)
to me it's a shame it's curly braces across the board with some minor, if notable exceptions. these new languages like Gleam, this one, and more could really do more to move things along here. Kudos to Scala 3 for making a move towards a quieter syntax. see, while it's a cliche, almost, to say, syntax does not matter, it absolutely does. it's what your eyes see, so the quieter it is, in general, the less noise it has, the better, imo.
I feel similarly, though when Pony was mentioned I checked it out and was pleasantly surprised by its syntax. Text now seems to me more like a protocol between the editor and the programming language, I've seen some of the stuff Lisp people are doing with visual programming that looks awesome as well.
@@lwinklly yup. I also liked how Coffeescript looked. and ofc Euby and so on. really love quiet syntax, the concept itself.
I showed Coffeescript to a FE friend of mine who does TS/react on our team and he hated it. but it's just -- I feel like -- cause it's relatively unfamiliar to someone used to C-like syntax exclusively.
you should get Gabriella Gonzalez on to talk about Haskell and Dhall :-) Maybe fall-from-grace even :-P
I'd love to! She's totally in my personal Hall of Fame.
I did try to get her on a few months back, but couldn't get a hold of her. Maybe it's time to gently try again. 🤞
nice, thx
imho: just fix rust....its about the eco system
no, the issues with rust aren't ecosystem related
Fix rust, auto insert an infered lifetime if possible and problem solved, not ecosystem