I loved hearing about Louis’ slow development philosophy! It makes me feel better about some projects at work that I started developing or thinking about at some point, only to finish them a couple years later. It seems very true that having these things on the back burner for a while makes them more consistent and well thought out somehow. Looking forward to getting back to Gleam!
Erlang pattern matching + function overloading and exporting functions based on name and arity can produce extremely clean API's for your modules, honestly really really like that aspect of erlang... The full stops and uppercase variable names on the other hand took some getting used to, actually want to give it another try now that I'm older and wiser
the world needs thousands of new programming languages because the world changes mindset constantly and the world keeps learning about new ways to do things to mentally frame things
Just listened to the audio version - looking forward to fiddling around with Gleam :) - also kudos Kris on your inaugural episode. Well-structured interview, nice production values (always appreciated), informed questions, well-executed on all counts. Plus a cat ftw!
I really enjoyed listening to the audio version of this and only just twigged that it was on TH-cam :-). Really great interview. I must now find the time to check out Gleam.
Omg, I love Gleam! Kris, can we please have a update with Louis!!! It's such a cool language that brought me into the BEAM ecosystem, and it's come so far and the community around it is awesome!
Yes, I definitely want to get Louis back soon. And with a bit of luck & planning, I'll also have someone else from the lovely Gleam community on soon. 🥳
I really enjoyed this intelligent, friendly conversation. Thx, for recording it. Gleam is most certainly on my list. Also, I love Exercism. It's a great platform.
Really nice interview. I am going to check out Gleam! Used Erlang a little and Elixir a bit more to learn FP, but love small, clean, simple languages and tooling. Greatly appreciate the wonderful video!
Erlang is not an implementation of the actor model. Processes can be actors, but not all Actors are processes, actors are just an abstraction, anything that sends/receives messages/process one message at a time/send a response is an actor, and also sending and receiving and the other words are abstractions. An actor can be a UNIX process with multiple threads or a subroutine, etc. The paper is very thorough about it so it is a great idea to read it.
That's a really tough question. I don't think Louis' in any hurry to put the 1.0 badge on it, but I also know it's already in use in production. I guess it also raises the question, what does 1.0 mean? Production ready? Supported? Guaranteed not to make any major changes? Stack overflow already has answers to most of your questions? My impression is that what's already there is high quality enough to start relying on, but there's a lot of design work and fleshing out still to do. For anything more definite, I think you should probably head to the Gleam Discord and strike up the conversation. :-) discord.gg/Fm8Pwmy
@@DeveloperVoices regarding this version 1.0. I think this is such a "magic version". In the companies I've worked for, when a team of some programmer/developer wanted to use a new technology in a project, the CTO always stipulated that there was no permission for commercial use (and potential wasted budget) on technologies that were not (and here I quote) "minimally stable, i.e. at least version 1.0, provided versioning is carried out reliably". So while for me as a programmer, from a technical point of view, there is not much difference between 0.33v and 1.02v if I know that the technology is mature enough. In commercial projects, managers calculate the financial risk. Therefore, the rule there is usually 'the better is the enemy of the good' meaning that it is better to choose something potentially inferior but battle-tested because it is less financial risk. In conclusion, I think that this magical version "1.0" is simply needed to make it easier to convince business to use a technology commercially. ;)
@@DeveloperVoices the other point I'd like to make is one flaw I see in what's going on around Gleam. I am fascinated by Gleam. It looks like a great technology. Personally, I am a TypeScript developer. However, I've never had any commercial exposure to heavily functional programming, nor to languages created to be written primarily functionally. Therefore, what I write below is purely my opinion. I do not want it to be taken as some kind of dogmatic truth or, worse still, to provoke some kind of programming wars. New technologies need to catch some kind of publicity in the developer community in order to exist. According to my observation, one of the best ways to achieve this is when the community invests in teaching their technology. Unfortunately, I have to admit that in this field the functional programming world is doing very mediocrely (to put it mildly). If we compare the content related to tutorials for technologies related to object-oriented programming, we can see a huge variety, but above all topicality. On the other hand, one only has to search youtube for tutorials for functional languages. Most are noticeably outdated, often recorded in poor quality. This is very bad for the development of the community, especially when you consider that learning via youtube, udemy, etc. is now probably the most popular form of learning. I'm sad to see that Gleam suffers from the same problem - there is virtually no quality content online teaching Gleam in a structured way (the only material I've found is a Gleam track on exercism(dot)com, but that's categorically not enough!). I think Louis could definitely serve his community and his programming language better if, instead of another recording being a loose chat about Gleam, he created something more along the lines of educational content, in order to facilitate the influx of newcomers to the language and community, which should more than pay off in time. I'm keeping my fingers crossed for this project with the pleasure of completing further tasks on the Gleam track on exercism(dot)com
I love Erlang syntax, I don't see anything wrong with it. I really think that people who get put off by weirdness are just expressing their inner bigot.
4:00 If you always want language features from other languages, I hope this is a language, where you can easily implement new features like in List or Scopes.
Do you mean like something Racket-esque? I don't think Gleam intends to be a language where users can dynamically extend the language itself. It's a very interesting point in the design space though. Maybe we should do an episode on Racket... 🤔
@@DeveloperVoices I never used racket, it's just an extended Scheme, I think. But it's a Lisp, too. I don't like Scheme because of the macro system. I still prefer the Common Lisp Macro System, not the Scheme one, which also inspired Rust. >Maybe we should do an episode on Racket... 🤔 I'd prefer an episode on Scopes, which is still in development. It has many important language features buiiltin (low level by default), and it's easy to create new ones.
Gleam is a cool idea but I've already used Elixir and Rust in production together. They work rather well together for building NIFs or VNodes and you can reclaim a fair amount of performance while maintaining a fault tolerant system. To be fair though, many companies just use Erlang because they don't care so much about the syntax. I personally, am fine working with that prolog style syntax though I prefer the Elixir syntax more. it would be nice to have strict types though and also being able to compile to JS and WASM is a plus. You can't do that with traditional Elixir/Erlang. Though I wish Gleam had module level pattern matching like Erlang and Elixir do. Not being able to write multiple function heads is just a handicap imo.
@@DeveloperVoices Sure, but I don't know if it's the multiple function clauses or arity specification or for comprehensions that does it.. I think that the biggest thing that makes Erlang look different is that pattern-matching makes information hiding less common. So you end up parsing directly into bound values instead of just returning a single value that's bound to a single value. {this, That, _, Huh} = i_suspect:its_this_stuff().
> Is Gleam your next programming language? That's a no for me, the performance and computational footprint are terrible at this moment and although it can and will be improved, something tells me it has a ceiling. And BEAM is worse performant than JVM generally, so the language will probably not come close to the likes of Scala and Closure. You hear stories of people migrating from Elixir for a reason.
Thanks for having me on the show Kris!
It was an absolute pleasure. 🙂
Great work Louis
I loved hearing about Louis’ slow development philosophy! It makes me feel better about some projects at work that I started developing or thinking about at some point, only to finish them a couple years later. It seems very true that having these things on the back burner for a while makes them more consistent and well thought out somehow.
Looking forward to getting back to Gleam!
Yeah, it’s a great way to work, if you have time on your side. A real antidote to the sprint-treadmill.
Erlang pattern matching + function overloading and exporting functions based on name and arity can produce extremely clean API's for your modules, honestly really really like that aspect of erlang... The full stops and uppercase variable names on the other hand took some getting used to, actually want to give it another try now that I'm older and wiser
Wait, types on Beam? I’ve had dreams about this.
the world needs thousands of new programming languages because the world changes mindset constantly and the world keeps learning about new ways to do things to mentally frame things
Just listened to the audio version - looking forward to fiddling around with Gleam :) - also kudos Kris on your inaugural episode. Well-structured interview, nice production values (always appreciated), informed questions, well-executed on all counts. Plus a cat ftw!
Thanks! I'm really glad you liked it. I'm looking forward to releasing many more. :-)
Such a good interview! I tried Gleam out today and I was impressed with the documentation tooling.
Awesome! Yeah, I've been having some fun with Gleam too - Louis' done a great job. :-)
I really enjoyed listening to the audio version of this and only just twigged that it was on TH-cam :-). Really great interview. I must now find the time to check out Gleam.
I hope you get a sponsor. This podcast is fantastic.
Thank you!
Omg, I love Gleam! Kris, can we please have a update with Louis!!! It's such a cool language that brought me into the BEAM ecosystem, and it's come so far and the community around it is awesome!
Yes, I definitely want to get Louis back soon. And with a bit of luck & planning, I'll also have someone else from the lovely Gleam community on soon. 🥳
@@DeveloperVoices Awesome!
@@DeveloperVoices cant wait! i wonder who it is...hayleigh? giacomo? idk anybody else lol
"Spawn a number of actors" 50:49 that's what Stellan Skarsgard did
Please add chapters to these 🙏
I’ve been trying out gleam for the last couple of months and I’m loving the experience so far.
Good interview, it was interesting to watch
I really enjoyed this intelligent, friendly conversation. Thx, for recording it. Gleam is most certainly on my list. Also, I love Exercism. It's a great platform.
Thank you so much for this just absolutely excellent interview series, you’ve surfaced so many people and projects I would have never found otherwise!
Really nice interview. I am going to check out Gleam! Used Erlang a little and Elixir a bit more to learn FP, but love small, clean, simple languages and tooling. Greatly appreciate the wonderful video!
Great stuff! Got this from a friend and will share it!
Subbed the moment he mentioned bleeps and bloops.
Erlang is not an implementation of the actor model. Processes can be actors, but not all Actors are processes, actors are just an abstraction, anything that sends/receives messages/process one message at a time/send a response is an actor, and also sending and receiving and the other words are abstractions. An actor can be a UNIX process with multiple threads or a subroutine, etc. The paper is very thorough about it so it is a great idea to read it.
I’ve been using the exercism gleam track, and it’s been so great!
Gleam is looking quite polished with v1.0
algebraic effects is so cool
Hii, please how can I learn gleam... There aren't much resources online (makes sense cuz it's relatively new)
I'd try the recently-released Exercism track: exercism.org/tracks/gleam
IIRC, it was written by Louis, so you'll be in good hands. :-)
syntax matters a lot to me, lol, i just wrote off learning roc because it hasn't got braces
Any predictions as to when we will reach version 1.0 and readiness for use in commercial projects?
That's a really tough question. I don't think Louis' in any hurry to put the 1.0 badge on it, but I also know it's already in use in production.
I guess it also raises the question, what does 1.0 mean? Production ready? Supported? Guaranteed not to make any major changes? Stack overflow already has answers to most of your questions?
My impression is that what's already there is high quality enough to start relying on, but there's a lot of design work and fleshing out still to do. For anything more definite, I think you should probably head to the Gleam Discord and strike up the conversation. :-)
discord.gg/Fm8Pwmy
@@DeveloperVoices regarding this version 1.0. I think this is such a "magic version".
In the companies I've worked for, when a team of some programmer/developer wanted to use a new technology in a project, the CTO always stipulated that there was no permission for commercial use (and potential wasted budget) on technologies that were not (and here I quote) "minimally stable, i.e. at least version 1.0, provided versioning is carried out reliably".
So while for me as a programmer, from a technical point of view, there is not much difference between 0.33v and 1.02v if I know that the technology is mature enough. In commercial projects, managers calculate the financial risk. Therefore, the rule there is usually 'the better is the enemy of the good' meaning that it is better to choose something potentially inferior but battle-tested because it is less financial risk.
In conclusion, I think that this magical version "1.0" is simply needed to make it easier to convince business to use a technology commercially. ;)
@@DeveloperVoices the other point I'd like to make is one flaw I see in what's going on around Gleam.
I am fascinated by Gleam. It looks like a great technology. Personally, I am a TypeScript developer. However, I've never had any commercial exposure to heavily functional programming, nor to languages created to be written primarily functionally. Therefore, what I write below is purely my opinion. I do not want it to be taken as some kind of dogmatic truth or, worse still, to provoke some kind of programming wars.
New technologies need to catch some kind of publicity in the developer community in order to exist. According to my observation, one of the best ways to achieve this is when the community invests in teaching their technology.
Unfortunately, I have to admit that in this field the functional programming world is doing very mediocrely (to put it mildly). If we compare the content related to tutorials for technologies related to object-oriented programming, we can see a huge variety, but above all topicality. On the other hand, one only has to search youtube for tutorials for functional languages. Most are noticeably outdated, often recorded in poor quality. This is very bad for the development of the community, especially when you consider that learning via youtube, udemy, etc. is now probably the most popular form of learning.
I'm sad to see that Gleam suffers from the same problem - there is virtually no quality content online teaching Gleam in a structured way (the only material I've found is a Gleam track on exercism(dot)com, but that's categorically not enough!). I think Louis could definitely serve his community and his programming language better if, instead of another recording being a loose chat about Gleam, he created something more along the lines of educational content, in order to facilitate the influx of newcomers to the language and community, which should more than pay off in time.
I'm keeping my fingers crossed for this project with the pleasure of completing further tasks on the Gleam track on exercism(dot)com
I predict March, 2024.
I would recommend learning from Elm in that reaching Ver 1.0 does matter, in a psychological sense.
I think Erlang has much nicer syntax than Elixir, but the tooling has not aged well. Gleam looks like an improvement over both
I love Erlang syntax, I don't see anything wrong with it. I really think that people who get put off by weirdness are just expressing their inner bigot.
“Erlang is weird. And I’m saying that as a Lisp/Haskell guy”
Yiiiikkkeess. When a Lisp dev thinks a language is weird…
😂
4:00 If you always want language features from other languages, I hope this is a language, where you can easily implement new features like in List or Scopes.
Do you mean like something Racket-esque? I don't think Gleam intends to be a language where users can dynamically extend the language itself. It's a very interesting point in the design space though.
Maybe we should do an episode on Racket... 🤔
@@DeveloperVoices I never used racket, it's just an extended Scheme, I think.
But it's a Lisp, too.
I don't like Scheme because of the macro system. I still prefer the Common Lisp Macro System, not the Scheme one, which also inspired Rust.
>Maybe we should do an episode on Racket... 🤔
I'd prefer an episode on Scopes, which is still in development. It has many important language features buiiltin (low level by default), and it's easy to create new ones.
@@porky1118wow forgot about scopes. I gotta check that out again
Bit hard to hear you in the mix over the music on my tv speakers
Oops, sorry. Hopefully that's better in recent episodes - I was still finding my feet for this one. 😊
@@DeveloperVoices Thanks, I really enjoyed the interview! I subscribed, and am excited to see more!
I love how they were almost flirting in the beginning of the video. love my queer programming fellas
Bad Regex! so apropos, I think Louis was foreshadowing the future. LOL!
Why didn't you let the cat in? 😅
Nice polish
Gleam is a cool idea but I've already used Elixir and Rust in production together. They work rather well together for building NIFs or VNodes and you can reclaim a fair amount of performance while maintaining a fault tolerant system. To be fair though, many companies just use Erlang because they don't care so much about the syntax. I personally, am fine working with that prolog style syntax though I prefer the Elixir syntax more. it would be nice to have strict types though and also being able to compile to JS and WASM is a plus. You can't do that with traditional Elixir/Erlang. Though I wish Gleam had module level pattern matching like Erlang and Elixir do. Not being able to write multiple function heads is just a handicap imo.
Oh that's very interesting - I didn't realise you could run Rust code inside the BEAM. 💡🙂
Super dumb comment. We want a statically typed language for the BEAM. Not C subroutines written in Rust that Elixir or Erlang calls.
Anything is more popular that F# 🤣
I can neither confirm nor deny. I’m Switzerland. 😅
I honestly don't think Erlang looks bad at all...
Can we agree on...unusual? 😁
@@DeveloperVoices Sure, but I don't know if it's the multiple function clauses or arity specification or for comprehensions that does it..
I think that the biggest thing that makes Erlang look different is that pattern-matching makes information hiding less common. So you end up parsing directly into bound values instead of just returning a single value that's bound to a single value.
{this, That, _, Huh} = i_suspect:its_this_stuff().
the c syntax is the one thing that keeps me away from Gleam.
> Is Gleam your next programming language?
That's a no for me, the performance and computational footprint are terrible at this moment and although it can and will be improved, something tells me it has a ceiling. And BEAM is worse performant than JVM generally, so the language will probably not come close to the likes of Scala and Closure. You hear stories of people migrating from Elixir for a reason.
I think JavaScript is a failed attempt to create wasm.
😅
stop renaming rust as different language :D
I’m pretty sure all modern programming languages are just three assembly language instructions in a trench coat. 😁
Stopped at 17 seconds
Dang, I’ll have to get my rhetorical devices to pay off more quickly next time. 😅
Stopped at 3200 seconds.