Erlang for boomers, Elixir for millennials, and Gleam for Gen Z? Iunno aboot that. I've never seen those three groups be this friendly to each other. :P
I have tried to stop me for quite a while but today is the day i can't anymore.. Please stop making these faces on your thumbnails, they never match how you actually respond to the video.
So stoked about Gleam: - Simple like go (small surface area) - Can leverage Elixir and Erlang tools - Scalable and fault tolerant (BEAM) - Type-safe and functional - Familiar to rust users (option/result and pattern matching) - `use` as a solution to callback hell (instead of async/await function coloring)
I used elm once in a production app. Absolutely loved it. Someone came in 3 years later and replaced it because they could not be bothered to learn it.
The language looks very promising! It really shows that there was a lot of thought put into the structure and has learned from what worked best and did not work from the other programming languages such as Elixir, JavaScript, Go, Python, etc.
yeah it's this, and as an elixir guy idk if i can manage. i *love* overloading arguments like that, i fucking *love* my left justification, i *hate* nesting
@@lpil down the road - allow the user to decide - method overloading is super convenient - if they want inference in their callbacks etc, then they won't overload. I do realize that overloading usually a burden to implement, so save it for later, but it's convenient for users
The thing about pipes. It's very awkward to type "|>" on a non ANSI-keyboard layout. Programming languages are definitely made for American and British layouts, but the rest of the world already have to wrangle semicolon, and curly brackets being hidden behind modifier keys.
I feel that way about certain characters too, and I've got a US keyboard. Here we call () parentheses or parens, {} braces and [] brackets. I prefer brackets for most things because I don't have to hit shift to type them, but I still use braces often in writing code because it just makes sense. However, I did toy with the idea of an all bracket version of LISP. It looked weird, but I think people could get used to it.
I bought a keyboard with ansi layout 3 years ago and put the lost keys (ä,ü,ö,ß) on another layer that I trigger with caps (press -> esc, hold -> layer). Works beautifully. I use keyd on linux and on windows you can use their ancient keyboard layout creator to use altGr key instead of capslock. If I were to use Gleam I would just put |> on that layer and it would become perfectly ergonomic. Still need to look into ZMK/QMK to see if it's possible to have everything on the keyboard itself. I think it pays to invest a bit of time or money into ones tools.
I too didn't like implicit returns when I first saw then in Ruby many moons ago. Wasn't until Rust that their value really clicked for me, and all the elegant expression block syntax they enable.
A reason I like implicit return is that it makes it very obvious whenever there is a code path that branches out of the function, besides the main (often the happy) path
I’ve gotten curious at some point and wrote a typesafe pipeline library for TS. Turns out, it doesn’t solve much, as unlike Elixir, the whole stdlib isn’t designed in a way that puts first argument first, meaning, even if you go crazy with syntax sugar, it still doesnmt feel right and looks messy. Add async/await to it and its impossible to debug and stack traces are useless 😢
Gleam looks pretty awesome! It's honestly really funny to see you go through the playground and be super excited about all these language features like type inference, blocks, and pattern matching. I'm already used to all these features from Rust! Gleam seems very similar to Rust overall but the garbage collection and easy JS transpile are finessed as fuck.
I think "rust but trade a bit of performance for some ease of use" is something a lot of people want. Arguably it's why Go is so popular but go is lacking some niceties from Rust. Rust's type system and error handling are amazing but I don't want to think about lifetimes, and its async situation is tricky. Worth it if you need the Perf, but most of the time I don't
@@SeanLazerI agree that it's desirable to have all these great things in a GC language! I do write in Rust and I usually never have to think about lifetimes. 😄 That mostly comes up if you're writing libraries for others to use, especially if your library is full of generics or is highly concurrent. Me, I'm just writing application code. I use Rust because its type system makes modeling logical problems so much easier. Sometimes I'm working on a problem that has to iterate over hundreds of thousands of files and pull data out of them, or reformat them, etc. and I can use as much .clone() etc as I want!
@@SeanLazer tricky is an understatement. it's a mess. I use rest but I think people tend to pretend it's performance is worth all it's complexity. you have to remember that to even get that performance really* you have to write some complex rust. rust compile time is also quite horrendous. I initially like rust but honestly it's development time is quite stagnating
The ever-growing RUclips presence of new-language-fanbois is growing increasingly annoying. Web development is dead, and it's now being kept alive with toy languages and pretty buttons.
Super pumped to get back into Gleam now it’s hit 1.0. Been following it for years. It’s been a long road, and Louis and the team has iterated and tried out a lot of things, threw out a bunch of stuff that didn’t fit quite right, and ended up in a really nice sweet spot. Elixir is Erlang but better. Gleam could well be Elixir but better.
I am not sure about this one. What is its strength? Seems like there are better languages around for various use cases, that do it better in those situations (eg Rust) The sales pitch sounds nice but overall it still is somewhat in an uncanny valley. Doesn’t even have OTP (and iirc won’t ever fully get there?) I would rather use Elixir and NIFs.
Really fascinating language, I'm all for ML like languages that place a decent emphasis on static type-safe systems. I wish more languages / tools existed like this for building highly dynamic client-side applications!
Amazing, takes all the features I love of Rust and simplifies it by trading off the fine grained memory layout / control which is fine for many software use cases. Literally been thinking of creating a language like this, I will definitively try and contribute to this! Nice video!
The thing I am most curious about is what would happen to Gleam once Elixir's static types system is ready for production. The biggest thing about Gleam is its static typing. Other than that, the language is either very similar to Elixir, or worse in some cases (no function overloading). I guess being able to run on Javascript runtimes might be a benefit, but at that point aren't you better off just using typescript instead?
In systems where you have elixir/gleam on the backend being able to compile to TS/JS is useful as you dont have to go through hoops to call your function in a different lang
@@dandogamer My question is, why would you ever want to compile to JS in the first place? If it is server side, you might as well keep it in the BEAM world. If it is frontend based, Elixir (Phoenix actually) already allows you to just write JS/TS directly.
@@VoidstroyerThe same reason everything is JS nowadays: you don't have to learn a different language, you can reuse type definitions, validation between back/frontend
Also, another thing they have is syntax (i'm not sure about semantics), i'd say it's familiar to Rust/Zig/Go/JS devs, and maybe even C/C++/Java, whereas elixir is similar to Ruby, and erlang is similar to itself. To existing erlang/elixir devs that probably means nothing, but in a world where people don't even want to leave JS for another C-like lang, familiarity is a good way to attract people to the ecosystem. For one, I'll be trying gleam in some toy projects or AoC. I've tried elixir, but the ruby syntax which i'm not familiar with is a deterrent. And erlang is erlang.
@@araozu I understand the argument of "keeping it in the same language" but that is also one of the biggest problems with web dev nowadays. People using JS for everything. Just because you can, doesn't mean you should. To be honest, if you are already really adept at writing JS, learning a different backend language such as Go (or any OOP language) is so trivial. At this point it is just stuborness of JS devs to not want to use a different language for the backend. I didn't list elixir because I did have some issues getting used to Functional programming. But given some time it is really not an issue. I like Elixir & Phoenix because it allows you to use most of Elixir for your webapp, and if you need heavy client side stuff you can just write JS directly. It enables you to use "the right tool for the job". And since I don't see JS devs leaving it all behind for Gleam, I also don't see Gleam getting that much adoption. But hey, I could be completely wrong. But I do believe that once Elixir gets its static type system ready, it is definitely going to negatively impact Gleam.
Even though it's still in private beta, Jai is still my dream/favorite language. It was initially made for making video games, so it's made to be performant, both in the code being fast, and the compiler being fast, but it's also useful for a lot of other use cases to, as it's also a replacement for C/C++
To me, Gleam is a huge disappointment. The BEAM is great, but it lacks macros and pretty much everything else that separates Elixir from Erlang. The language simply isn't expressive enough to make a framework like Phoenix or even to make something on par with Ecto! It fails to empower solo devs and small teams in the way Elixir or even Erlang could and yet it's still immutable and functional and poorly suited for projects with large numbers of cheap devs the way Java/.Net/TS is. Gleam just doesn't excel at anything.
It's sad that it doesn't try to compete Go's async/multithreading standards with goroutines. Like, where does gleam stand now in this whole "Production languages" list from C++, Rust to Typescript, Python to Go being in the middle? I'm placing it after Go (in terms of not covering this humongous market) of software engineers wanting languages that are simple but also very performant. And Gleam does not seem to touch that market as much as Go does. It just seems to "Gleam" .... i don't know who will use it instead of Go, and why.
They seem to prefer elixir concurrent model and more functional style while go is more procedural Go is pretty good, but in my opinion is not the favorite of many devs because of err != nil and not having a strict null checker This language seems to have strict null checker like rust which reduces drastically bugs caused by skill issue They said that the language does not have null and that I doubt, they probably have null with another name
Big disagree on the performance take at the start of the video. Javascript isn't slow because it lacks good concurrency, it's slow because it allocates really nice syntax to really slow operations. Javascript is actually a really fast language but if you use rest, spread, async/await, map/filter, .forEach, promises, closures, etc. it *becomes* slow. Simple languages are appealing because they are often designed in a way that the "path of least resistance" also leads to great performance
As someone really familiar with Rust, I can't help but laugh a little when you point at Rust features and say they're really nice ergonomics. Aside from the pipe operator (which is excellent don't get me wrong!) this entire demo read identically to Rust code for me. Regardless, very cool to see development in the language space. JS, TS, C++, etc. need to get into gear. They're rapidly being outpaced by much nicer languages to work in.
The main difference is that Gleam is a smaller language, thus making it easier to learn. Having all of the features and more is not always a good thing. I like rust but it sometimes feels like C++ if C++ was invented 10 years ago (I mean in the large amount of features and the general complexity of the language)
@@defalur That definitely is the biggest distinction in philosophy between the two languages. Having said that, Gleam seems to lean more heavily into custom operators like >. for int vs float disambiguation. While that does make it easier to infer the type signatures for things like functions, it does also remove the possibility of a library defining types which also use those operators. Aside from that, it looks like you can just use Gleam code in Rust with only minor changes to the semantics. Where Rust definitely is bigger is in concepts like Async, traits, and generics. I completely agree these things do add complexity to Rust, and there are examples of languages that don't need them (Go and C being the biggest examples). An important distinction in my mind tho is that Rust doesn't have bloat in things that you shouldn't use. While there exists many different Async environments and strategies, none of them are wrong. Whereas in C++ and C, there are definitely wrong things you can reach for (e.g., non-owning pointers, etc.) One thing I find interesting is Gleam, being a more functional language, completely prohibits mutability. That's definitely a viable strategy, but is certainly more complex and restrictive for certain algorithms than Rust's borrow checker, a frequent pain point for new adopters.
@@zactron1997 I disagree - C definitely needs traits, generics, or something of the sort. Relying on macros and void * is awful. C might be "simple". But because it is so simple it creates complex code. Basic paradigms have to be implemented in round-about ways... which is why C++ was invented in the first place. I think Go, to a lesser extent now, suffers that same problem.
@@lucass8119 personally, I agree. I think Go and C are too simplistic for the kind of complex problems an average programmer is expected to work with. Go mostly avoids this problem by having such an exhaustive standard library, but it still has issues. That's why I personally think Rust is a better bet on future software, since it accepts that some concepts just are complex, and is attempting to meet that complexity head on.
16:25 onward looks almost identical to Rust. They even followed Rust in rejecting function overloading antipattern. Just last week I was talking with a friend the best replacement for the go niche would be simplified Rust with a garbage collector with the good Rust type-system. I just wish it had traits. Pipes look like a useless gimmick to me, especially when you have to use that awkward _
Gleam is a very exciting language for BEAM, but just keep in mind that OTP is the true engine behind what makes coding on BEAM unique, and the Gleam standard library currently wraps very little of OTP. This is not a criticism, I'm sure it will be easier to make progress on this with a stable language, and the language author loves the runtime.
"we know what a float is", then proceeds to skip over the part where it explains how BEAM floats are different than floats in other languages (no [-]Infinity or NaN, and division by zero equals 0). Being an elixir fanboy Theo himself probably knows this already, but I'd guess most of his subscribers are JS devs who are not aware of BEAM's float rules, so I thought I'd mention
This is a cool project but honestly I don't think it's at the point where I would want to abandon elixir for it. It might be useful to work with both languages, but I've been doing a lot of rust plus elixir work recently (they pair so well together), and I just don't see where gleam fits into all of that. It's definitely a cool language and it will bring more people into the ecosystem which is nice, I plan to dive into it to see what the 1.0 releases really like. Probably the most contentious issue I have with the language is the fact that OTP is not included automatically, and I have to wonder if that has something to do with the multiple back ends that they provide. That and I also wish that it had modular level pattern matching/function overloading like erlang or elixir. I knew that they wouldn't have it because they weren't including the argument amount for each function, which is kind of important if you going to do function overloading in that way. It's easily run my favorite features of elixir / erlang. Edit: I spent some time writing a distributed cache system in gleam. It's the kind of project that is somewhat trivial in elixir if you leverage otp. I found that gleam had a lot of really rough edges especially when it came to interop. The ETS library is deprecated, it's from 0.23 or something of the language and so I had to write my own wrappers. It was relatively easy to do this but I noticed that it was very easy to ignore the static type system by using generics and dynamic types (makes sense given that elixir / erlang are dynamic). One of the reasons why I really like using rust with elixir is because of rust's result and option monads, they make it easy to do error handling on the elixir side by simply passing atoms back to the system which minimizes the downside of using NIFs. On the other hand, when you are wrapping elixir with gleam, because gleam is the language that has results, you kind of have to work around the potential to get a nil or error atom. It definitely works but it's not as intuitive. I also really don't like the actor abstraction, it's just not as intuitive as genserver. I basically ended up writing my own wrapper around genserver. It's definitely rough to try to implement Genserver without function overloading but I was able to make my own pattern within the genserver behavior by passing calls, cast, and infos off to an elixir function. I was able to build a basic supervision tree and implement most of the stuff that I wanted to create, but it did take me a lot more time than it would have taken in elixir because I had to write all of these wrappers. That being said, if the community starts to build more libraries, I don't think this should be as much of a problem in the future. It just kind of sucks that a lot of the OTP functionality hasn't been exposed yet and so you kind of have to go and get it yourself if you want it. It also really doesn't play well with static typing, which is probably why they are trying to build a set-based type system in elixir.
I don't underestand why languages, especially new ones, don't have named imports, like in JavaScript. That's the thing I appreciate the most about JavaScript. It's such an easy win, but of the languages I know only Python and Zig do that.
gleam does have named imports, you use the `as` keyword (if you know rust, it's just how rust does it) so `import gleam/string as str` or a more complex example `import gleam/string.{reverse as rev, append as app}`
The main reason to use TS/JS is having the ability to not switch languages if you write frontend / complex web apps. I do not see this advantage challanged, where are many good backend languages out where -> but they are all not good enough if you want to do frontend.
I predict that pretty soon we'll see new programming languages and libraries released alongside LLM AIs to help developers convert their existing code bases and reduce onboarding
I found Gleam is kinda not so good. It feels more like a new syntax than a new language. There are too many differences between the JS and BEAM runtime: integers, floats, async is mildly/very different between the runtimes, to the point where it's hard to write code that works on both runtimes.
I keep seeing all these new languages coming out but they keep trying to approach but falling short of CL or even Clojure. The Pipelines syntax is just the threading macro from Clojure, which is available as a macro in Common Lisp too (cl-arrows). Programmers are putting themselves through so much pain and effort just to avoid a few extra parentheses and prefix notation
I don't get it people complaining about the JS choice and then complaining about concurrency if we can use web workers and if JS is not been used for web is already wrong, the point is that JS is not a comparison choice to new language because JS have done its job with its limitations, but because it is popular and catch people attention. Ok would be awesome to have such brand new languages to be the browsers choice, but they are not and will not be, so, anyway, I don't get it.
21:09. But JS does have that. It's just not as obvious. In JS I usually just: const farenheit = (() => { let degrees = 64 console.log() return degrees; }())
I mean beam officially is not optimised for any sort of CPU bound computation. It’s far slower than V8. If your thing does not require some crazy concurrency, I mean implementing paxos level of complexity, don’t bother with not even erlang. And even then, just don’t. First 10kloc you write in a new language will be absolute bullshit anyways and someone needs to port to golang or something in a year.
it's funny when I go into FP via Haskell & Closure just as a hobby, I don't code for living or for love, it seemed like it was the answer to so many of the things I hated bout programming. now everybody who codes for a living is all over FP, in some partial way at least. it I never would have guessed JS would adopt TS as a default by 2024.
The fact that JS got imports so wrong tells me how good the people that design the language are. Like they are absolute geniuses and luck and timing had nothing to do with their success.
Lots of projects are having a hard time even allowing people to participate. Making y PR sometimes takes forever to be reviewd or will never be. that does not motivate people to support activly and participate. At least what I experienced.
I saw only 1 comment about Scala. Gleam and Scala are both VM languages. BEAM vs JVM? I guess that people who are familiar with both BEAM & JVM worlds or Scala & Gleam worlds don't do youtube videos.
Sounds like you'd definitely like Julia. It can use emojis as variables, has block context scoping, implicit _or_ explicit returns, _and_ function overloding is the whole basis of the langauge. Also compiles down to LLVM, so it is as fast at Rust.
Wow. I almost dismissed Gleam because of its name and icon. I know that's a bad heuristic, but you gotta prioritize where to put your attention, you know. But boy am I glad that I watched this video. Gleam looks awesome. The design and syntax just makes me want to use it.
Elixir for gen z lets goooooooooooooooooo
Erlang for boomers, Elixir for millennials, and Gleam for Gen Z?
Iunno aboot that. I've never seen those three groups be this friendly to each other. :P
Rust for Beam lol
@@user72974You missed Gen X
@@BinaryReaderthat's the middle child no one cares abt
@@BinaryReader who?
I have tried to stop me for quite a while but today is the day i can't anymore.. Please stop making these faces on your thumbnails, they never match how you actually respond to the video.
so funny that people actually care
So stoked about Gleam:
- Simple like go (small surface area)
- Can leverage Elixir and Erlang tools
- Scalable and fault tolerant (BEAM)
- Type-safe and functional
- Familiar to rust users (option/result and pattern matching)
- `use` as a solution to callback hell (instead of async/await function coloring)
Why is it scalable and fault tolerant ?
@@GreatTaiwanLook into Erlang/BEAM
@@GreatTaiwanBEAM is built for that, gleam doesnt do much extra for scalability
The one hesitation I have is a 53 stars postgres beam package. Is there a more proven package?
@@GreatTaiwan I runs the Taiwan local elixir meetup, if you are curious, come and join us and find out. :)
functional programming, algebraic data types, and web frameworks using the elm architecture... this will be fun to try
I used elm once in a production app. Absolutely loved it.
Someone came in 3 years later and replaced it because they could not be bothered to learn it.
Iced is a GUI Rust library that uses the elm architecture
I can already see job posts: 11 years of experience in this language for junior roles
Lmao
That wouldn’t be too crazy as I assume Erlang experience translates.
Tech leads speed running the making of insane interview questions for Gleam
I literally said "I think this is my dream language" when I first saw gleam! I'm glad it's resonating with other people too!
Functional language with simple C-style syntax, running on BEAM, statically typed, and cool mascot.
Literally cant ask more than that!
Two counters reset in 24h, jeez
lmfao
Mind saying what the counters are counting, for someone who isn't in on the joke?
@@nmotschidontwannagivemyrea8932 “X days since a new JS framework” and “X days since a new programming language”
@@t3dotgg Lol ty
What's the new JS framework? Tanstack Start? It was a few days ago. There's a new one?
louis, the gleam creator, is also extremely awesome and runs a great discord server
awesome human
The language looks very promising! It really shows that there was a lot of thought put into the structure and has learned from what worked best and did not work from the other programming languages such as Elixir, JavaScript, Go, Python, etc.
Ahh thank you Theo!!!
No function overloading is most likely a compromise for good type inference
yeah it's this, and as an elixir guy idk if i can manage. i *love* overloading arguments like that, i fucking *love* my left justification, i *hate* nesting
Yeah, compromise between having a simple language and full HM inference. Type classes are a big jump in complexity
Yup that’s it
Good type inference _and_ function captures.
Function overloading makes alot of more valuable features much harder to implement
@@lpil down the road - allow the user to decide - method overloading is super convenient - if they want inference in their callbacks etc, then they won't overload. I do realize that overloading usually a burden to implement, so save it for later, but it's convenient for users
Why does it have to be so political?
Because nazis are bad and queer people should feel welcome.
Lol, i literally started trying gleam today and im loving it, now theo uploads a video about it. Life is good
Same! It's awesome 😍
I've been writing a lot of go lately but this feels like what i was actually looking for
The thing about pipes. It's very awkward to type "|>" on a non ANSI-keyboard layout. Programming languages are definitely made for American and British layouts, but the rest of the world already have to wrangle semicolon, and curly brackets being hidden behind modifier keys.
I feel that way about certain characters too, and I've got a US keyboard. Here we call () parentheses or parens, {} braces and [] brackets. I prefer brackets for most things because I don't have to hit shift to type them, but I still use braces often in writing code because it just makes sense. However, I did toy with the idea of an all bracket version of LISP. It looked weird, but I think people could get used to it.
Also is really repetitive
str
|> String.reverse
|> String.split
Way better just
str.reverse.split 🤷🏻♂️
I bought a keyboard with ansi layout 3 years ago and put the lost keys (ä,ü,ö,ß) on another layer that I trigger with caps (press -> esc, hold -> layer).
Works beautifully.
I use keyd on linux and on windows you can use their ancient keyboard layout creator to use altGr key instead of capslock.
If I were to use Gleam I would just put |> on that layer and it would become perfectly ergonomic.
Still need to look into ZMK/QMK to see if it's possible to have everything on the keyboard itself. I think it pays to invest a bit of time or money into ones tools.
BTW, as a brit, £ is not a euro, it's a pound. € is a euro. 👍
Who cares about type safety? The logo is nice, I'M IN
I too didn't like implicit returns when I first saw then in Ruby many moons ago. Wasn't until Rust that their value really clicked for me, and all the elegant expression block syntax they enable.
A reason I like implicit return is that it makes it very obvious whenever there is a code path that branches out of the function, besides the main (often the happy) path
This guy simply reads stuff from the webpage.. why even watch this?
Woohoo! I'm an Erlang programmer and I love seeing new BEAM languages. Been following Gleam since the first announcements and I'm excited for 1.0.0
I’ve gotten curious at some point and wrote a typesafe pipeline library for TS. Turns out, it doesn’t solve much, as unlike Elixir, the whole stdlib isn’t designed in a way that puts first argument first, meaning, even if you go crazy with syntax sugar, it still doesnmt feel right and looks messy. Add async/await to it and its impossible to debug and stack traces are useless 😢
Effect-ts
is this another garbage collected rust? (to be honest, I like it more than ocaml)
Gleam looks pretty awesome! It's honestly really funny to see you go through the playground and be super excited about all these language features like type inference, blocks, and pattern matching. I'm already used to all these features from Rust! Gleam seems very similar to Rust overall but the garbage collection and easy JS transpile are finessed as fuck.
I think "rust but trade a bit of performance for some ease of use" is something a lot of people want. Arguably it's why Go is so popular but go is lacking some niceties from Rust. Rust's type system and error handling are amazing but I don't want to think about lifetimes, and its async situation is tricky. Worth it if you need the Perf, but most of the time I don't
@@SeanLazerI agree that it's desirable to have all these great things in a GC language! I do write in Rust and I usually never have to think about lifetimes. 😄 That mostly comes up if you're writing libraries for others to use, especially if your library is full of generics or is highly concurrent.
Me, I'm just writing application code. I use Rust because its type system makes modeling logical problems so much easier. Sometimes I'm working on a problem that has to iterate over hundreds of thousands of files and pull data out of them, or reformat them, etc. and I can use as much .clone() etc as I want!
@@SeanLazer tricky is an understatement. it's a mess. I use rest but I think people tend to pretend it's performance is worth all it's complexity. you have to remember that to even get that performance really* you have to write some complex rust.
rust compile time is also quite horrendous.
I initially like rust but honestly it's development time is quite stagnating
Omg you always on hype. When you do your job?
It's so funny how Theo keeps praising features that are also part of Rust, while also hating on Rust 😅
The ever-growing RUclips presence of new-language-fanbois is growing increasingly annoying. Web development is dead, and it's now being kept alive with toy languages and pretty buttons.
Super pumped to get back into Gleam now it’s hit 1.0. Been following it for years. It’s been a long road, and Louis and the team has iterated and tried out a lot of things, threw out a bunch of stuff that didn’t fit quite right, and ended up in a really nice sweet spot. Elixir is Erlang but better. Gleam could well be Elixir but better.
I'm just finding out what it is,
i never knew they've been working on it
It does not seem to be better than Elixir. Its just different.
Character is too cute to ignore
I am not sure about this one. What is its strength? Seems like there are better languages around for various use cases, that do it better in those situations (eg Rust) The sales pitch sounds nice but overall it still is somewhat in an uncanny valley. Doesn’t even have OTP (and iirc won’t ever fully get there?)
I would rather use Elixir and NIFs.
Obligatory nitpick : "75k Euros" while looking at British Pounds (and no it didn't change with brexit)
Really fascinating language, I'm all for ML like languages that place a decent emphasis on static type-safe systems. I wish more languages / tools existed like this for building highly dynamic client-side applications!
Amazing, takes all the features I love of Rust and simplifies it by trading off the fine grained memory layout / control which is fine for many software use cases. Literally been thinking of creating a language like this, I will definitively try and contribute to this! Nice video!
21:31 - can't you just do open/close curly brackets to arbitrarily define a new scope?
lol the whole lsp was released as a binary, Theo. It’s been a neovim package since before v1.
Discord was also built on the Erlang VM, and last time I checked, they were handling a billion (literally) daily messages.
The thing I am most curious about is what would happen to Gleam once Elixir's static types system is ready for production. The biggest thing about Gleam is its static typing. Other than that, the language is either very similar to Elixir, or worse in some cases (no function overloading). I guess being able to run on Javascript runtimes might be a benefit, but at that point aren't you better off just using typescript instead?
In systems where you have elixir/gleam on the backend being able to compile to TS/JS is useful as you dont have to go through hoops to call your function in a different lang
@@dandogamer My question is, why would you ever want to compile to JS in the first place? If it is server side, you might as well keep it in the BEAM world. If it is frontend based, Elixir (Phoenix actually) already allows you to just write JS/TS directly.
@@VoidstroyerThe same reason everything is JS nowadays: you don't have to learn a different language, you can reuse type definitions, validation between back/frontend
Also, another thing they have is syntax (i'm not sure about semantics), i'd say it's familiar to Rust/Zig/Go/JS devs, and maybe even C/C++/Java, whereas elixir is similar to Ruby, and erlang is similar to itself.
To existing erlang/elixir devs that probably means nothing, but in a world where people don't even want to leave JS for another C-like lang, familiarity is a good way to attract people to the ecosystem.
For one, I'll be trying gleam in some toy projects or AoC. I've tried elixir, but the ruby syntax which i'm not familiar with is a deterrent. And erlang is erlang.
@@araozu I understand the argument of "keeping it in the same language" but that is also one of the biggest problems with web dev nowadays. People using JS for everything. Just because you can, doesn't mean you should. To be honest, if you are already really adept at writing JS, learning a different backend language such as Go (or any OOP language) is so trivial. At this point it is just stuborness of JS devs to not want to use a different language for the backend. I didn't list elixir because I did have some issues getting used to Functional programming. But given some time it is really not an issue. I like Elixir & Phoenix because it allows you to use most of Elixir for your webapp, and if you need heavy client side stuff you can just write JS directly. It enables you to use "the right tool for the job". And since I don't see JS devs leaving it all behind for Gleam, I also don't see Gleam getting that much adoption. But hey, I could be completely wrong. But I do believe that once Elixir gets its static type system ready, it is definitely going to negatively impact Gleam.
i believe mojo also has emoji support!
Yeah sure is nice that another new language pops up to make videos off of and rake in views, huh?
Even though it's still in private beta, Jai is still my dream/favorite language. It was initially made for making video games, so it's made to be performant, both in the code being fast, and the compiler being fast, but it's also useful for a lot of other use cases to, as it's also a replacement for C/C++
20:01 Technically, Rust allows using emojis as variable names as well but you'll be getting warnings.
It's really funny to me just how much Theo hates Rust
did you just call £ "euros" 🤨 #BrexitMeansBrexit
To me, Gleam is a huge disappointment. The BEAM is great, but it lacks macros and pretty much everything else that separates Elixir from Erlang. The language simply isn't expressive enough to make a framework like Phoenix or even to make something on par with Ecto!
It fails to empower solo devs and small teams in the way Elixir or even Erlang could and yet it's still immutable and functional and poorly suited for projects with large numbers of cheap devs the way Java/.Net/TS is. Gleam just doesn't excel at anything.
The capture for just one argument is sad.
In Elixir it would be &add(1, &1, &2)
piping straight into capture is a +1 for Gleam though
It's sad that it doesn't try to compete Go's async/multithreading standards with goroutines.
Like, where does gleam stand now in this whole "Production languages" list from C++, Rust to Typescript, Python to Go being in the middle?
I'm placing it after Go (in terms of not covering this humongous market) of software engineers wanting languages that are simple but also very performant.
And Gleam does not seem to touch that market as much as Go does.
It just seems to "Gleam" .... i don't know who will use it instead of Go, and why.
They seem to prefer elixir concurrent model and more functional style while go is more procedural
Go is pretty good, but in my opinion is not the favorite of many devs because of err != nil and not having a strict null checker
This language seems to have strict null checker like rust which reduces drastically bugs caused by skill issue
They said that the language does not have null and that I doubt, they probably have null with another name
Go's concurrency system is unsound and Gleam prefers to use an actually good concurrency system. It looks like Go but good.
Big disagree on the performance take at the start of the video. Javascript isn't slow because it lacks good concurrency, it's slow because it allocates really nice syntax to really slow operations. Javascript is actually a really fast language but if you use rest, spread, async/await, map/filter, .forEach, promises, closures, etc. it *becomes* slow. Simple languages are appealing because they are often designed in a way that the "path of least resistance" also leads to great performance
Tldr: "It is a really fast language but if you uses anything it becomes slow"
@@luishenrique932 Good faith tldr: it's fast but if you use any of the modern syntax it's slow.
As someone really familiar with Rust, I can't help but laugh a little when you point at Rust features and say they're really nice ergonomics. Aside from the pipe operator (which is excellent don't get me wrong!) this entire demo read identically to Rust code for me.
Regardless, very cool to see development in the language space. JS, TS, C++, etc. need to get into gear. They're rapidly being outpaced by much nicer languages to work in.
The main difference is that Gleam is a smaller language, thus making it easier to learn. Having all of the features and more is not always a good thing.
I like rust but it sometimes feels like C++ if C++ was invented 10 years ago (I mean in the large amount of features and the general complexity of the language)
@@defalur That definitely is the biggest distinction in philosophy between the two languages. Having said that, Gleam seems to lean more heavily into custom operators like >. for int vs float disambiguation. While that does make it easier to infer the type signatures for things like functions, it does also remove the possibility of a library defining types which also use those operators.
Aside from that, it looks like you can just use Gleam code in Rust with only minor changes to the semantics.
Where Rust definitely is bigger is in concepts like Async, traits, and generics. I completely agree these things do add complexity to Rust, and there are examples of languages that don't need them (Go and C being the biggest examples). An important distinction in my mind tho is that Rust doesn't have bloat in things that you shouldn't use. While there exists many different Async environments and strategies, none of them are wrong. Whereas in C++ and C, there are definitely wrong things you can reach for (e.g., non-owning pointers, etc.)
One thing I find interesting is Gleam, being a more functional language, completely prohibits mutability. That's definitely a viable strategy, but is certainly more complex and restrictive for certain algorithms than Rust's borrow checker, a frequent pain point for new adopters.
@@zactron1997 I disagree - C definitely needs traits, generics, or something of the sort. Relying on macros and void * is awful. C might be "simple". But because it is so simple it creates complex code. Basic paradigms have to be implemented in round-about ways... which is why C++ was invented in the first place. I think Go, to a lesser extent now, suffers that same problem.
@@lucass8119 personally, I agree. I think Go and C are too simplistic for the kind of complex problems an average programmer is expected to work with. Go mostly avoids this problem by having such an exhaustive standard library, but it still has issues. That's why I personally think Rust is a better bet on future software, since it accepts that some concepts just are complex, and is attempting to meet that complexity head on.
Having `5 / 0 == 0` and `5.0 /. 0.0 == 0.0` is the most stupid decision I've ever seen in a programming language.
I'm such a huge fan of elixir, and gleam feels like elixir 2.0 super excited about it
another functional programming language that will be used in 5 projects
16:25 onward looks almost identical to Rust. They even followed Rust in rejecting function overloading antipattern.
Just last week I was talking with a friend the best replacement for the go niche would be simplified Rust with a garbage collector with the good Rust type-system. I just wish it had traits.
Pipes look like a useless gimmick to me, especially when you have to use that awkward _
How are pipes a gimmick? Chaining function calls is a basic necessity.
@@RegrinderAlertWhat's the benefit to Gleam pipes over Rust's thing.iter().map().collect() style?
Gleam is a very exciting language for BEAM, but just keep in mind that OTP is the true engine behind what makes coding on BEAM unique, and the Gleam standard library currently wraps very little of OTP. This is not a criticism, I'm sure it will be easier to make progress on this with a stable language, and the language author loves the runtime.
I'm happy too. My favourite language before I learnt about Erlang/Elixir was Prolog 😂
Gleam creator's youtube channel: www.youtube.com/@lpil
"we know what a float is", then proceeds to skip over the part where it explains how BEAM floats are different than floats in other languages (no [-]Infinity or NaN, and division by zero equals 0).
Being an elixir fanboy Theo himself probably knows this already, but I'd guess most of his subscribers are JS devs who are not aware of BEAM's float rules, so I thought I'd mention
I haven't read a lot of docs, but this is, by far, the most cleverly designed one I've read so far.
This is a cool project but honestly I don't think it's at the point where I would want to abandon elixir for it. It might be useful to work with both languages, but I've been doing a lot of rust plus elixir work recently (they pair so well together), and I just don't see where gleam fits into all of that. It's definitely a cool language and it will bring more people into the ecosystem which is nice, I plan to dive into it to see what the 1.0 releases really like. Probably the most contentious issue I have with the language is the fact that OTP is not included automatically, and I have to wonder if that has something to do with the multiple back ends that they provide.
That and I also wish that it had modular level pattern matching/function overloading like erlang or elixir. I knew that they wouldn't have it because they weren't including the argument amount for each function, which is kind of important if you going to do function overloading in that way. It's easily run my favorite features of elixir / erlang.
Edit: I spent some time writing a distributed cache system in gleam. It's the kind of project that is somewhat trivial in elixir if you leverage otp. I found that gleam had a lot of really rough edges especially when it came to interop. The ETS library is deprecated, it's from 0.23 or something of the language and so I had to write my own wrappers. It was relatively easy to do this but I noticed that it was very easy to ignore the static type system by using generics and dynamic types (makes sense given that elixir / erlang are dynamic). One of the reasons why I really like using rust with elixir is because of rust's result and option monads, they make it easy to do error handling on the elixir side by simply passing atoms back to the system which minimizes the downside of using NIFs. On the other hand, when you are wrapping elixir with gleam, because gleam is the language that has results, you kind of have to work around the potential to get a nil or error atom. It definitely works but it's not as intuitive.
I also really don't like the actor abstraction, it's just not as intuitive as genserver. I basically ended up writing my own wrapper around genserver. It's definitely rough to try to implement Genserver without function overloading but I was able to make my own pattern within the genserver behavior by passing calls, cast, and infos off to an elixir function. I was able to build a basic supervision tree and implement most of the stuff that I wanted to create, but it did take me a lot more time than it would have taken in elixir because I had to write all of these wrappers. That being said, if the community starts to build more libraries, I don't think this should be as much of a problem in the future. It just kind of sucks that a lot of the OTP functionality hasn't been exposed yet and so you kind of have to go and get it yourself if you want it. It also really doesn't play well with static typing, which is probably why they are trying to build a set-based type system in elixir.
I don't underestand why languages, especially new ones, don't have named imports, like in JavaScript. That's the thing I appreciate the most about JavaScript. It's such an easy win, but of the languages I know only Python and Zig do that.
Python is older than JS
So why they don’t have it like Python
Just saying
WDYM? Rust doesn't have named imports?
gleam does have named imports, you use the `as` keyword (if you know rust, it's just how rust does it)
so `import gleam/string as str` or a more complex example `import gleam/string.{reverse as rev, append as app}`
Gleam does have named imports
The main reason to use TS/JS is having the ability to not switch languages if you write frontend / complex web apps.
I do not see this advantage challanged, where are many good backend languages out where -> but they are all not good enough if you want to do frontend.
Kotlin
You can frontend in Rust :P
I predict that pretty soon we'll see new programming languages and libraries released alongside LLM AIs to help developers convert their existing code bases and reduce onboarding
I’ll check it out I hated elixir but let’s see 😅
Me too, but just seems like elixir without ruby influence added some rust syntax
Just what we need: Another language. Hopefully this will be followed by another javascript framework.
that literately looks like the solidjs tutorial
I found Gleam is kinda not so good. It feels more like a new syntax than a new language. There are too many differences between the JS and BEAM runtime: integers, floats, async is mildly/very different between the runtimes, to the point where it's hard to write code that works on both runtimes.
High Level rust, lets gooooooooo!!!!!!
this is nothing close to the binary abomination that is rust lol.
so a bad rust!
@@trejohnson7677 what is a "binary abomination" supposed to be?
@@potatomaaan1757 run xxd or some shit guy.
I think it's not "implicit return". Function should return something and there is no null in Gleam. It's just what it is.
>friendly
lol
It looks really close to Rust lang.
Finally a Type Safe Elixir!!! I am 100% on board. Sign me up!
20:00 PHP also allows emoji variables, to add to your list 😛
Common Lisp supports emojis as variable names.
I keep seeing all these new languages coming out but they keep trying to approach but falling short of CL or even Clojure. The Pipelines syntax is just the threading macro from Clojure, which is available as a macro in Common Lisp too (cl-arrows). Programmers are putting themselves through so much pain and effort just to avoid a few extra parentheses and prefix notation
go still better with a broader use case but this has a cooler type system and js runtime support
Gotta agree, this looks really neat and has me looking over the fence...
I don't get it people complaining about the JS choice and then complaining about concurrency if we can use web workers and if JS is not been used for web is already wrong, the point is that JS is not a comparison choice to new language because JS have done its job with its limitations, but because it is popular and catch people attention. Ok would be awesome to have such brand new languages to be the browsers choice, but they are not and will not be, so, anyway, I don't get it.
21:09. But JS does have that. It's just not as obvious. In JS I usually just:
const farenheit = (() => {
let degrees = 64
console.log()
return degrees;
}())
I mean beam officially is not optimised for any sort of CPU bound computation. It’s far slower than V8.
If your thing does not require some crazy concurrency, I mean implementing paxos level of complexity, don’t bother with not even erlang.
And even then, just don’t.
First 10kloc you write in a new language will be absolute bullshit anyways and someone needs to port to golang or something in a year.
it's funny when I go into FP via Haskell & Closure just as a hobby, I don't code for living or for love, it seemed like it was the answer to so many of the things I hated bout programming. now everybody who codes for a living is all over FP, in some partial way at least. it I never would have guessed JS would adopt TS as a default by 2024.
Still Zig ain't 1.0
The fact that JS got imports so wrong tells me how good the people that design the language are. Like they are absolute geniuses and luck and timing had nothing to do with their success.
That was a nice video, very well meaning and positive. Love it!
Lots of projects are having a hard time even allowing people to participate. Making y PR sometimes takes forever to be reviewd or will never be. that does not motivate people to support activly and participate. At least what I experienced.
But you can't do UI stuff with it, so its a pass for me
no emojis for variable names, thats good.
Theo, the Scala language is running out of sponsors, I think it is worth a look
21:57
For situations like this, i would love "return" to return from the whole function, and "ret" to return from within your mini closure
Boooooooo being annoying about people using camel case booooooooooo
You can use emojis as variable names in C.
The language looks cool... but do we really need the stupid little star? I can't see how that's going to help it's adoption.
16:50 "Big web frameworks don't even have this." React and next, you mean react and next dont have this.
That is gross. Really horrible. Another crap nobody will use it.
Literally seems like a inferior version of Kotlin, that already has everything this language is bringing to the table lmao
Ah, no explict return means no guard clauses, I don't like that. I don't want extra indentation
I saw only 1 comment about Scala. Gleam and Scala are both VM languages. BEAM vs JVM? I guess that people who are familiar with both BEAM & JVM worlds or Scala & Gleam worlds don't do youtube videos.
Take a look at "Erjang" (with a "J", for JVM). Doesn't seem to be active anymore but it's an interesting idea.
Sounds like you'd definitely like Julia. It can use emojis as variables, has block context scoping, implicit _or_ explicit returns, _and_ function overloding is the whole basis of the langauge. Also compiles down to LLVM, so it is as fast at Rust.
Swift mentioned!
I might be in the minority but i don't like the syntax, too many silly symbols everywhere
If it runs on JS runtimes I expect it to run on the JVM as well....
If whisp gets a feature like Phoenix's LiveView I'm going all in.
Wow. I almost dismissed Gleam because of its name and icon. I know that's a bad heuristic, but you gotta prioritize where to put your attention, you know.
But boy am I glad that I watched this video. Gleam looks awesome. The design and syntax just makes me want to use it.