The Inko Programming Language, and Life as a Language Designer (with Yorick Peterse)
Vložit
- čas přidán 16. 07. 2024
- This week we take a close look at the programming language Inko from two perspectives: The language design features that make it special, and the realities of being a language developer.
Yorick Peterse joins us to discuss why he’s building Inko, and which design sweetspots he’s looking for. We begin with memory management, aiming for the kind of developer who wants control, but without the complexities of Rust. Then we look at the designing for concurrency with typed channels, and handling exceptions by removing them and leaning heavily into ADTs and pattern matching.
Mixed in with all that is a discussion on the realities of being a programming language developer. How do you figure out how to implement your ideas? What tradeoffs do you make and what kind of programmer do you want to be most useful to? How do you teach people new ideas in programming, and how “different” can you make a language before it feels weird? And perhaps the hardest question of all: How do you fund a new programming language in 2024?
-
Inko’s Homepage: inko-lang.org/
Inko Source Code: github.com/inko-lang
Yorick’s Homepage: yorickpeterse.com/
Ownership You Can Count On (paper): inko-lang.org/papers/ownershi...
“The Error Model”: joeduffyblog.com/2016/02/07/t...
Kris on Mastodon: mastodon.social/@krisajenkins
Kris on LinkedIn: / krisjenkins
Kris on Twitter: / krisajenkins
-
0:00 Intro
2:48 Inko’s Target Audience
5:47 Memory Management
10:57 Concurrency
15:35 How Do You Learn This Stuff?
21:42 The Recovery Algorithm
33:25 The Tradeoffs of Language Design
40:42 Tips For A New Language Writer
44:10 Typed Channels for Concurrency
54:23 How Much Can A Language Innovate?
1:02:12 Inko’s Approach to Error Handling
1:06:29 Should ADTs Be Part Of Every Language?
1:10:12 How Do You Fund A New Language?
1:16:53 Funding Open Source Software
1:21:28 Getting Started With Inko
1:23:18 Outro
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!
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.
Inko seems like a really nice extension of Nushell-I’d love to see the async features there.
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.
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.
Gleams implementation of concurrency doesn't require using dynamic or any other reduction in type guarantees.
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.
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.
cool episode :)
Getting C interop is the most important thing. This would also solve TLS support.
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