ERRATA: 5:19 - `task.try_await` doesn't protect you from the task crashing, only from timeouts. The correct way to avoid crashing the host process would be to use a supervisor. `try_await` will, however, return an error if the process EXITS with an exit code. If the process panics or is killed, the host process will crash. 9:11 - Yes, yes. It's POLYNOMIAL, not exponential.
You have to write FFIs to get them to work with the type system, unfortunately, but it's quite easy to do. People are writing ORMs in Gleam as it's easier to do that than to try and FFI onto something that dynamic. I'm sure it's possible though
Exactly my thought, and even worse, he then proceeds to use a solution that wouldn't even work in production because 'Actors' cannot handle concurrency. How is that convincing anyone? 😄
@@Meknassih you misunderstand the provided solution. Actors *do* handle concurrency, by design. They aren't recommended as a permanent solution here because they will act in a somewhat synchronous fashion (FIFO single-threaded evaluation). For the point of the demonstration, it is more than sufficient. For a real application that could see many thousands of requests per second, it would be worth the additional effort to grab a more performant, if less user-friendly, solution.
This new toy in town seems fun, I just wanted to add a side note: if there's one thing that is becoming too complicated in the current programming world, is not the Backend precisely (I will argue the opposite) but the frontend (that has fully embraced the Javascript hell) is quite more complicated today than it was a decade ago
It really seems to me that Gleam is the truth. 1. High-level feel with GC 2. Functional but simple 3. Strongly and Statically typed 4. Errors as values 5. Exhaustiveness 6. Built-in Scalability due to the Beam I like that
@@remcogreve7982 I think that's an Erlang thing. Gleam has a divide function in the standard library that'll return an `Error` if you try to divide by zero, if you want to use that
"must never crash" it's not how you write reliable software. Your app must crash, but you should make it so that users don't notice it. I other words it should be able to tolerate crashes and still have close to 100% uptime
wtf is that terrible advice, apps/apis should NEVER crash. Specially APIs. If a user crashes your API, it'll down for everyone else unless you have multiple instances deployed, and even IF you had multiple instances deployed, why would you knowingly let it crash? wtf lol
The ethos of the BEAM is "let it crash", but that generally applies to single processes. The idea is that it's better to let a process (e.g. a task in Gleam) crash than try to recover and make a load of error handling mess
@@user-93fekod1o you should let program crash on unexpected error because it was unexpected and it doesn't know how to handle it, unless of course you know in advance how to handle an unexpected error in which case you would not have time to write comments on youtube.
How did you not mention OTP in this entire rant (which I loved and agreed with). Does your stack have agents? Oh wait Gleam is the answer to all of this. I approve. Just snarky about people seeming to not realize, "we've been solving this since the 60's"
Very good point! And yeah, I've been getting deeper and deeper into Erlang-land recently watching conference talk videos. It's really fascinating to me
That's not the only selling point. Gleam runs on the Erlang BEAM VM, so yes, it does have great concurrency, but it's also incredibly fault tolerant, type safe, and a joy to write. It also has great error handling and a really nice community :)
I'm glad someone is doing some videos with gleam!! Would love to see some more about the gleam OTP and concurrency. Also some simple web dev stuff like how do I connect it to a postgres db etc
I demonstrated the cache in the video, and as for the message queue, concurrency in Gleam is often handled using actors, which have a mailbox that acts as a queue, processing a single message at a time! It's quite easy to build systems on top of that to replicate fanout queues and so on too. In fact, RabbitMQ, one of the most popular messages brokers, is built on the same virtual machine Gleam uses!
I still don't get the `use` syntax. I've tried to understand it through the documentation and more but I just can't get to understand what it does and when it works. It said something about returning the value of the function that was a parameter or something like that and I really don't get how to use it. It seems like a great feature but I just can't wrap my head around it.
Having spent the past week playing around with Gleam I don't think it's very good. - Poor standard library (have to use Erlang for basically everything, even taking input from stdin). - Base data structures are bad (slow). - Have to compile everything to Javascript or you get Python levels of performance. - Being unable to return early from functions makes the language feel like ass to write once you start trying to do anything complex. - Pattern matching is meh. You're often nesting pattern matches inside pattern matches and it results in code that's a complete mess. - Documentation is terrible and unfinished.
The first point is a fair criticism, but there's some stuff that's not included deliberately. Generally, something will only be in the stdlib if it has a consistent behaviour across Erlang and JS. Reading from stdin doesn't. Gleam is not designed for ultimate performance - it's designed for scalability. Lack of early return is normal for functional languages, but Gleam allows you to simulate early return with `use It's not common to have more than one or two levels of matching. Can you show me an example? This is a fair point - the language documentation needs work. Great opportunity for some OSS contributions😉
@IsaacHarrisHolt It must be said that performance and scalability go hand in hand. For example, I built an ABSURDLY optimized piece of python code. As optimized as you can get before bit magic. All this to taste a fraction of Go with the same degree of complexity. Not everyone can afford the cloud equivalent of 2 Xeons for every project. If python ran like go. The internet would run 90% cheaper.
I use and work daily with C#, even for API stuff, and so far everything I used it for just work fine as expecting Its not always the fault of the language but also the programmer implementing it, good working code can be written in most good languages without issues Even on my job we use C# day in day out, software engineer here, we also use other languages but my section is purely based on C#
Totally fair! C# can be a good language for that sort of thing, but you still have to reach for external services or micro services to achieve a lot of the things you can achieve in BEAM languages like Gleam. And you're right, you can write good code in any language. That said, some languages make it easier than others to maintain a high standard.
Elixir does the same and in most cases looks the same. But sometimes it gets annoying when You write pattern matching and think about fancy handling. So annoying that want to return to Ruby, PHP, NodeJS unfortunately.
@@IsaacHarrisHolt that's question of taste - who loves patterns who loves try catches, who loves Option, Result types, somebody goes unwrap. I'm Elixir I solved it by writing result handling function overloading and piping. Not everyone is pattern matching lover.
@@IsaacHarrisHolt Thank you! I'm excited to try out Gleam to do similar tasks I've used Elixir for! I remember when Gleam first started, the project has changed alot in the past 2 years. Interesting to see the JS focus as well, almost sort of a strange choice of effort? Still not sold on that.
the only advantage gleam has over elixir is static types. anyone that's used elixir knows it doesn't need static types. although they are working on gradual types, but you don't have to annotate them if you don't want.
Gleam's also a lot easier to learn. While Elixir is great, it does have a steep learning curve for folks who've not touched the BEAM before. Gleam makes a lot of that easier. Also, Gleam compiles to JS, so you can run it in the browser for a full stack development experience without needing the compromises of something like LiveView (namely latency)
Nothing is better than Go for backend. 1. Everything you need is in the std library 2. Syntax is dead simple. 3. Concurrency is dead simple. 4. I’ve never written cache handler longer than 50 lines of code in Go. Having the cache as a separate process (ie redis) provides a fault tolerant system.
Go is great! I agree with your first three points for sure. On the last one, with the BEAM, your cache can be a separate process, or even on a separate node, but still be in your program, and still be perfectly fault tolerant!
I tried Gleam by making the usual higher-lower game but I got stuck and couldn't find in any docs how to read from stdin so I left and haven't gone back. Seems like a nice language. I'm sure I just skill issued myself hard.
The BEAM doesn't have the best story for CLI applications, honestly. That's unfortunately a limitation of the platform, given it's not what it was designed for. I'd suggest trying out a web server or some other project :)
Wrong domain! I don't think it's a con either. For compiled languages I'd say the closest functional feel language is OCaml and the closest simplicity feel language is Go for CLI software.
You could, but Gleam's type system makes it easier to have large-scale projects, and makes refactoring a lot easier. Plus, you can use all your Elixir libs!
I have one question, is the play_button / triangle ligature in your font this: "|>" ? edited: I read the code, it seems like it is... I was confused how to make that for a moment haha
Looks interesting, I've been following Gleam development for some time now. I'm bound to try it out at some point. For the time being though it looks like a watered down and less mature version of Scala.
Interesting take, for sure. Have a go and let me know what you think :)
8 місяців тому+5
I honestly don’t really get why i should switch from Go to Gleam? What are the benefits? I could get how the BEAM is more explicit with errors and more fault tolerant than e.g. goroutines But I’ve also heard that gleam is far less performant?
You're not wrong! Gleam is less performant than Go as it's not a compiled language. However, as you said, error handling and fault tolerance are better, and it's MUCH easier to create distributed systems with the BEAM. On top of that, Gleam's type system is much better than Go's. You don't need to worry about nil pointers, nil structs etc., and you get proper sum types rather than the error-prone kinda-enums you get in Go. Plus, there will, at some point, be a native target for Gleam, which will improve performance (though you'd lose the BEAM).
8 місяців тому
@@IsaacHarrisHolt Oh man, guess I have to learn another new language now :D I think I was put off by Javascript being a compilation target, but I guess I can just ignore that and do stuff with Erlang. I can't seem to find a lot of benchmarks out there, so do you know what an average performance delta there is?
Great video! As a rust dev not convinced of gleam though. Feels like this is almost easier to implement with actix. Plus not having to deal with the erlang VM also sounds like a great advantage to me.
Fair points. For me, I prefer not having to deal with the borrow checker, move semantics, lifetimes, and Rust async etc.. Gleam makes it much easier to deal with concurrency
that video had alot to unpack, too much for my brain, that's complex, grug brain can't get all of it, 50% was over my head, time to re watch this, keep this good work up
@@IsaacHarrisHolt Honestly, I think its mostly just the pattern matching, fp in a c-like syntax and the immutable data structures. What I don't like about it is that you can write it just like Java or just like Haskell or an unholy mix of the two. I also seems to add any feature dreamed up by any PHD student into the standard language.
There are a few startups being built in Gleam, and a few Gleamlins have managed to get it into prod at their companies. I couldn't tell you who, though. As for unstructured data, Gleam handles it like any other strongly typed language - you have to try and decode it into a Gleam type to work with it. There's _technically_ a Dynamic type, but you can't interact with Dynamic values except to decode them or just pass them around, so if you don't need to know the shape of the data at any point at all, you can just use that
I know the feeling! I wanna learn more about both databases and distributed systems, and it seems like Zig would be better for one, and Gleam the other 😅
@@IsaacHarrisHolt that's the exact dilemma I'm having. No doubt I'll find time to dabble in both, but I'd love to master something other than Go! I do love Gleams erlang roots though...agh decisions decisions!
Comparing what? At what scale? Between which languages? What are we measuring and why is that important? What are we measuring? It's never as simple as just "do a performance benchmark".
Rust is famously difficult to make parallel??? How easy it is to parallelize complex code without introducing race conditions and stuff like that is one of it's main selling points. And with rayon, its extremely nice and easy to parallelize simple stuff. Rust certainly is not the easiest language to learn but in no world is it "famously difficult to make parallel".
@@1vader I would say writing concurrent rust code, is having the extreme benefits as well as problems of Rust. It is very hard to start but easier to master as other programming languages. Stuff like performance optimized async traits, tower services and the general Sync + Send + 'static requirement aren't easy to get right at the start. There are other languages that get you going faster, for example Go, where you can just write `go function()` to make something "parallel". Of course, rust has this concurrency model because of good reasons, but knowing them is a must to understand and work with them. In conclusion, I would say Rust can be easy for experienced users, but they are a headache for beginners and I wouldn't recommend them this approach at the begin of their rust journey.
I don't understand the point of this video when I can do all of the mentioned stuff in C# and faster, too. Although Gleam does sound interesting worth as a side project for exploring it
Go did get a mention! Right at the start. I just didn't draw many comparisons because in some ways, Go is very similar. It's also one of my favourite languages, but I like Gleam for having proper sum types and no nulls :)
I don't understand, in what language is the equivalent code for this going to 'blow up in your face'? If the only difference is the Option type, I don't think thats a really convincing argument to switch, or even try to learn an entirely new language just for that
Any language that uses exceptions makes control flow practically invisible. You have to have some global try/catch block in your code. Gleam allows you to handle errors where they crop up
@@IsaacHarrisHolt agree with you on that. However that just makes me like go even more, it returns error as a value, and as a dev you have to make the conscious decision of ignoring an error
@@_theone_99 that's no different to Gleam or Rust, in reality. The benefit of Gleam over Go is that you have proper sum types and don't have to worry about nil, and therefore nil pointer exceptions
@IsaacHarrisHolt yep, weird decision from the creators to not have an option type. I am hopeful about sum types though, hopefully they introduce it soon.
@@IsaacHarrisHolt gleam threw a lot of great stuff from erlang to the trash in favor of an imperative programming style, absolutely not a fan of that. Not having macros and/or reflection is a deal breaker to me, I tend to write nowadays a lot of declarative code that uses these feature under the hood to process the declarations. As for the types, the only rule is to validate external data, use typespecs and static tools like dialyzer to get almost the same precision in your codebase, having the added benefit to use fully dynamic values where you don't need a precise data shape.
@@IsaacHarrisHolt In real-world applications this kind of complexity is not a reality. We use elixir in production because it is extremely good in terms of readability, extensibility and core libraries. Portions that need types to be checked can be covered by libraries like NimbleOptions (BTW the feature level this library has is what a good type system should look like). If elixir manages to create the static type checker, languages like gleam will be not be of much relevance in the future.
I wish this video spent less time writing code and more explaining why gleam is superior for this use case. The example can be built in any language. I may not be the best listener but I wasn't able to understand how Gleams special feature make it suitable as a redis replacement.
Fair criticism! As for that, the short answer Gleam has some really great ways of having in memory kv stores thanks to Erlang and the BEAM. The long answer is a little more complicated, and one for research :)
@@IsaacHarrisHolt Incidentally I'm likely to use Gleam at work whereas I don't think Roc will ever be finished! Roc is made by one of the creators of Elm, which also inspired Gleam.
@@lawrencejob Yes! I watched one of the Roc talks. It looks interesting. And do let us know if you use Gleam at work! The community would love to know what you do with it :)
We have 20 concurrent languages. This is stupid. We should create one that fixes all these issues as a one stop solution. Now we have 21 concurrent languages. This is this video.
I don't like monolith codebases. I mean might need something to be re-written completely. What about database migration, file handling. Each language and runtime their own strength. So I'll rather use different languages and runtimes for different uses and connect all of them via pub/sub or stream.
Totally fair! My point in this video is that too many people reach for that by default. You see lots of companies running microservices when they have like, 10 users.
@@IsaacHarrisHolt Yeah that's true. I love the quote, "You shouldn't think about handling 1M users at the first place. When you have 1M users. You would love to have that problem."
Even Rust still doesn't have proper ecosystem. How much time would it take for Gleam to mature, huh? And the selling points aren't there either. Awesome concurrency exists in Go and Elixir. Why would I want Gleam? I want to get things done, not be a pioneer of yet another language. Meh.
Gleam can use Elixir and Erlang libraries, so you get the benefit of those mature ecosystems already, so no worries there. As for why you'd use Gleam over Go, it's mostly for the type system and the BEAM. I'm a massive proponent of Go, don't get me wrong, and I love writing it. But, Gleam's type system is a lot more robust. There are no nil pointers exceptions or gotchas like that, and Gleam has proper sum types. Give it a try and you'll see :)
Gleam compiles directly to JavaScript/Erlang. It has pretty much zero overhead over erlang so it's faster than elixir It also has FFI compatibility with elixir and Erlang if compiling to erlang and has FFI compatibility with JavaScript if compiling to JavaScript. There have been what feels like a million libraries to release since launch, rarely I need to do FFI but when I do it's fast syntax
@@mellowcloud6434 this is absolutely right. It compiles to Erlang which is then executed right on the VM. As to whether it's faster than Elixir, I've not done the tests. It's possible that Elixir produces more optimised bytecode at the end of the process than the Erlang that Gleam creates. It would be interesting to test.
@@mellowcloud6434 it can't be faster than elixir, both runs on same VM, are your sure it compiles down to erlang? usually beam languages put out beam binaries aka .beam file. if it does, then compilation should be slow.
I have been writing elixir for last four years, I like dynamic languages without too many type intervention, it's definitely a good to have when it comes to types. But elixir's community is so mature that everyone is nice enough to reply and write documented code. over the years I have noticed one thing with languages, the more easy you make a language to get started with, the more shit code that community generates. Look at Go, I have read so many codebases of Go, everything just abuses channels, just because compiles and works people be like okay, I'm right, not really care about quality.
When you say "other programing languages" just mean node/js. All others I know use threads (Or can use threads) just like gleam. Nice how you just discovered the "cache" trick.... Dude, that has been done on any other language with proper threads for ages, and, check that, you can do that even with DB connections it's called connection pooling. Yeah, a pool of connections for all processes, I know ... rad, just java 1995 style... Maan.. kids this days...
It's important to know that BEAM processes are not that same thing as threads. Most languages that allow threading will use OS threads, generally limiting you to 2x the number of cores in your machine. Gleam processes are closer to green threads. They're very lightweight, and you can have thousands of them per machine. I never claimed to have "discovered" keeping mutable state in another process. I was merely using it as an example of how powerful the BEAM is. Again, sure, you might be able to do this in other langs, but you'd have to have a mutex around your shared state.
@@IsaacHarrisHolt I also think that gleam is an elegant solution to most common multithreading cases. is just that you are comparing it to node and how node works. I would not say that's "most other languages" as you imply in the video. Much as the contrary, I would say that the node approach is the exception, not the norm. I could implement this beam model (not as elegantly, sure), on any of the languages I know. I've used similar constructs in java, for example. Not sure where you got that information, but you can have many many more OS threads than cores, (on linux, the default limit is 100k, i think, and can be expanded).
I wasn't comparing just to Node. I was using it as an example, sure, but I was actually comparing to most async/await systems, which do use an event loop. Python is the same, as is Tokio for Rust. Most of them are based on libuv or libuv-adjacent tech. Apologies - you're right, I was getting mixed up between OS and CPU threads. Yes, you could implement a lot of this with OS threads, but again, the BEAM and its mailbox system handle things in a graceful way such that you don't have shared memory and don't have the footguns that entails.
@@IsaacHarrisHolt you did the video, you're familiar with, im not familiar with so if you are talking about something to be friendly to new devs, my opinion is more valuable than yours because this is the first time i see gleam code. first time i saw rust or go or kotlin it was very easy to understand code, its syntax and its behavior, with this gleam that didnt happened and actually those operators i mentioned were not obvious to me, that's why im saying it seems complex. python decorators are only put @yourdecorator above a function, it is very simple and that's why frameworks like fastapi or flask are so popular. in my opinion your example seems too complicated having too much verbose code in too many files instead of having something simple like fastapi endpoint based on decorated functions or an express endpoint. you might not agree with me but for me it was harder to understand than other languages i've previously seen, so this one is not "simple" to me and maybe devs with similar background i have might think in a similar way.
That's fair, but my point was that having different syntax to what you're used to does not make a language complex. It's merely something you need to learn. And sure, using decorators in Python is simple, but I challenge you to try and recreate what FastAPI or Flask is doing under the hood. Not necessarily the whole thing, but just the decorators for registering a route. There's a lot going on there that's hidden from the user, which can make it difficult to debug etc.
The type safety myth... I'd love to know who these people are who need to stop themselves assigning a string to the variable `number`. Do you know what happens to python programmers who don't use type hinting? Nothing. Because mixing up types is either a sign of gross incompetence or, far more likely, the monster lurking in the child's cupboard. You know, there one that isn't there. If you're doing it for performance - that's perfectly valid, all power to you. If you're doing it as a crutch because you think you need your hand held - you almost certainly don't. Take those stabilisers off and just ride your bike like an adult.
This is definitely one of the comments of all time. You come across as though you've never worked on a large project with many developers. When writing software in teams, the best thing you can do is get the computer to do as much of the work for you as possible (auto formatting, lint checks, automated testing, etc.). Type checking is part of that - it reduces the mental load on each engineer, increasing the development velocity of the team as a whole. If you're relying on variable names to tell you their types, e.g. "number", you're basically introducing your own weak, inconsistent version of static typing anyway and creating more work for the people writing code and the people reviewing code. There are cases where dynamic typing is helpful, for sure, but for the work that 90% of people are doing, having static types is going to be a boon purely for the time it saves debugging issues. As much as anything else, static typing is a form of documentation. When you're onboarding new engineers onto a project, having types for them to read makes parsing the codebase infinitely easier - they don't have to keep all the context of all the types of every possible permutation of variables in their head to understand the flow of what's going on. And if you try to make the argument for documenting types in docstrings etc., again, you're using a poor-man's static typing. On the Python point, as someone who has written a fair bit of Python professionally, and used to make Python videos on this very UA-cam channel, a lot of the industry is moving towards using type hints as much as possible. The same trend can be seen in other popular dynamically typed languages - Elixir is getting a type checker built into the compiler, and Ruby's Sorbet is growing in adoption. Basically, all this to say... what??
I see. You're a proponent of the bloat approach. You're in a team so pile on the boilerplate and layer on the comments. "We can't take the stabilisers off the bike dad, it'll fall over." Let's agree to differ on that front.
Type annotations aren't bloat. Having to do more typing to make your life and your colleagues' loves easier is always worth it. Typing isn't your main job as a software engineer anyway.
@@IsaacHarrisHolt They literally are boilerplate. Listen, we clearly have very different ideas of what constitutes good code. You're the the verbose / explicit camp, I'm in the minimalist. Some experienced coders would agree with you and competent coders would agree with me. :)
And then there's me, thinking about solving your initial problem in Java Spring Boot in 20 minutes with no need for Redis or any other external service, perfectly fine error handling, exceptional stability, and clean, non-verbose code. People really overlook the "boring" languages in favor of the hottest language of the week which is more often than not made more for computers and less for humans (cough cough Rust).
@@cuca_devA big idea within ML inspired languages is that the simple things should be hard to make the complicated things easy. For an example of how this works you could watch Tsoding's video on making a JSON parser from scratch in Haskell.
I agree that Rust is probably a lot harder than it needs to be, but I disagree with you on Java's error handling. I'd much prefer errors as values to throwing exceptions.
@cuca_dev really? Writing one program is more cognitive load than deploying 10 microservices, RabbitMQ, Redis, and managing all of that? I'd prefer a single program, personally.
I think this current trend of favoring and shilling "the hottest languages" is not good for fresh juniors who's entering this industry. There are a lot more important and basic stuffs backend devs need to know before playing with Rust, Gleam or Elixir. I rather want juniors understand the things like SQL, POSIX commands, HTTP protocol, networking stuffs and how to write tests.
Gleam compiles to Erlang! So yes, it's very similar. But Gleam is statically typed, which brings a whole host of benefits around error handling and so on, as you can see
It's different, honestly. Sure, the performance probably won't match Rust's, but Gleam makes it very easy to parallelise (something that Rust is famously not). You also don't have to fight the borrow checker at every turn, and the type system (which is what most people love about Rust) in Gleam is based on Rust's, so you'll feel comfortable moving.
ERRATA:
5:19 - `task.try_await` doesn't protect you from the task crashing, only from timeouts. The correct way to avoid crashing the host process would be to use a supervisor. `try_await` will, however, return an error if the process EXITS with an exit code. If the process panics or is killed, the host process will crash.
9:11 - Yes, yes. It's POLYNOMIAL, not exponential.
A timestamp to 9:11 in an 8:47 video?
I love how the answer to too many programming language is always more programming languages.
But we know better, don't you see!
@user-fc8xw4fi5vbut c isn't inherently safe so we need a language that is safe.
Almost all the time
I waited to see if XkCd replied directly. Munroe, we prayed for you here!
how_standards_proliferate.xkcd
How to be a fresh backend developer?
It's simple, just:
-Migrate from PHP/Python/Perl to Go-
-Migrate from Go to Rust-
Migrate from Rust to Gleam
wonder what language is next week. all these rewrites are so productive
The difference is that Gleam already has a mature ecosystem thanks to being built on Erlang, so you don't have to reinvent all the basic packages
@@IsaacHarrisHoltthat argument also applies for kotlin, however Gleam is the new shiny thing so I guess it is cooler to try
@@IsaacHarrisHoltare they compatible with the type system. For eg how mature are the ORMs at this point? Gleam is so interesting btw
You have to write FFIs to get them to work with the type system, unfortunately, but it's quite easy to do. People are writing ORMs in Gleam as it's easier to do that than to try and FFI onto something that dynamic. I'm sure it's possible though
"Your backend is too complicated" -> "I'm going to skip explaining this bit because it's too complicated for this video" xD
Point taken, but it's difficult to fit stuff in 10 mins 😂
Exactly my thought, and even worse, he then proceeds to use a solution that wouldn't even work in production because 'Actors' cannot handle concurrency. How is that convincing anyone? 😄
@@Meknassih you misunderstand the provided solution. Actors *do* handle concurrency, by design. They aren't recommended as a permanent solution here because they will act in a somewhat synchronous fashion (FIFO single-threaded evaluation). For the point of the demonstration, it is more than sufficient. For a real application that could see many thousands of requests per second, it would be worth the additional effort to grab a more performant, if less user-friendly, solution.
@Meknassih it is somewhat remedied by the effortless concurrency vid
How many GIFs do you want to use in your video?
Isaac: Yes
Can't never have too many
@@IsaacHarrisHolt Yes you can and it totally turned me off on yet another friggin language.
Fair. This video style isn't for everyone :)
@@dabunnisher29👀
@@dabunnisher29have you considered evaluating a language based on its merits rather than the number of gifs in a video about the language?
This new toy in town seems fun, I just wanted to add a side note: if there's one thing that is becoming too complicated in the current programming world, is not the Backend precisely (I will argue the opposite) but the frontend (that has fully embraced the Javascript hell) is quite more complicated today than it was a decade ago
You're not wrong, but Gleam can simplify that too 😉 I'll be doing a video on full stack Gleam soon
@@IsaacHarrisHolt cool! Looking forward to see it, especially the deployment part
@@LuisM_Santana Ah, it'll probably just be Docker or Fly.io, to be honest. There's a good guide in the Gleam docs.
It really seems to me that Gleam is the truth.
1. High-level feel with GC
2. Functional but simple
3. Strongly and Statically typed
4. Errors as values
5. Exhaustiveness
6. Built-in Scalability due to the Beam
I like that
It's quickly become one of my favourite languages!
Only the divide by zero thing is really strange.
@@remcogreve7982 I think that's an Erlang thing. Gleam has a divide function in the standard library that'll return an `Error` if you try to divide by zero, if you want to use that
@@IsaacHarrisHolt Returning an error is at least better than having a wrong answer quietly. That is the worst option for handling errors imaginable.
Again, I think this is an Erlang limitation. I might be wrong on that, though. I agree that it's not the ideal scenario
"must never crash" it's not how you write reliable software. Your app must crash, but you should make it so that users don't notice it. I other words it should be able to tolerate crashes and still have close to 100% uptime
Yes, processes should crash, but the system as a whole should ideally never go down. That's what I was aiming for :)
wtf is that terrible advice, apps/apis should NEVER crash. Specially APIs. If a user crashes your API, it'll down for everyone else unless you have multiple instances deployed, and even IF you had multiple instances deployed, why would you knowingly let it crash? wtf lol
The ethos of the BEAM is "let it crash", but that generally applies to single processes. The idea is that it's better to let a process (e.g. a task in Gleam) crash than try to recover and make a load of error handling mess
@@IsaacHarrisHolt well yeah but you'd usually be using something like supervisor for important things
@@user-93fekod1o you should let program crash on unexpected error because it was unexpected and it doesn't know how to handle it, unless of course you know in advance how to handle an unexpected error in which case you would not have time to write comments on youtube.
Anyone know what font and color theme is being used in the text editor at around 1:30 ?
It's Neovim with JetBrains Mono, AstroNvim and astrodark
@isaacharrisholt man of culture
Just as a sidenote, the discord community for gleam is great too :)
It is! I'm reasonably active there, and I love it
How did you not mention OTP in this entire rant (which I loved and agreed with). Does your stack have agents? Oh wait Gleam is the answer to all of this. I approve. Just snarky about people seeming to not realize, "we've been solving this since the 60's"
Very good point! And yeah, I've been getting deeper and deeper into Erlang-land recently watching conference talk videos. It's really fascinating to me
What's the performance of gleam compared to other Backend langs and framework please
It's not a performance oriented language, so it's the same as the languages it compiles to. In this case, JS and Erlang
@@IsaacHarrisHolt thank you very much, so I would like to clarify if it's selling point is just concurrency ?
That's not the only selling point. Gleam runs on the Erlang BEAM VM, so yes, it does have great concurrency, but it's also incredibly fault tolerant, type safe, and a joy to write. It also has great error handling and a really nice community :)
The formula num_battles = n * (n-1) / 2 is quadratic in n, not exponential.
You're technically right, but most people don't say "it grows quadratically" or "it grows polynomially". "Exponentially" is just the common term :)
Well then it is the wrong term. How do you call something tha grows like 2^n?
@@IsaacHarrisHolt I've never seen that incorrect use before. Could you provide examples where you have seen it?
Something "growing exponentially" is quite a common phrase even outside of maths/comp sci
@@IsaacHarrisHolt common does not mean it supersedes the correct terms.
Polyonimial growth is ok, exponential is not. They're very different.
I'm glad someone is doing some videos with gleam!! Would love to see some more about the gleam OTP and concurrency. Also some simple web dev stuff like how do I connect it to a postgres db etc
Noted! Definitely going to do both.
How does gleam, make you not use a cache store nd a message queue 😅
Huh
I demonstrated the cache in the video, and as for the message queue, concurrency in Gleam is often handled using actors, which have a mailbox that acts as a queue, processing a single message at a time! It's quite easy to build systems on top of that to replicate fanout queues and so on too.
In fact, RabbitMQ, one of the most popular messages brokers, is built on the same virtual machine Gleam uses!
I still don't get the `use` syntax. I've tried to understand it through the documentation and more but I just can't get to understand what it does and when it works. It said something about returning the value of the function that was a parameter or something like that and I really don't get how to use it. It seems like a great feature but I just can't wrap my head around it.
Basically it just avoids some nesting. So instead of:
```
result.try(my_result, fn(ok_value) { logic() })
```
I can do
```
use ok_value
@@IsaacHarrisHolt Thanks for the clarification I think I'm getting the gist of it now! Seems pretty useful for sure.
@@aronjacobson5403 It's great for achieving sort-of-early-returns using `bool.lazy_guard`
Having spent the past week playing around with Gleam I don't think it's very good.
- Poor standard library (have to use Erlang for basically everything, even taking input from stdin).
- Base data structures are bad (slow).
- Have to compile everything to Javascript or you get Python levels of performance.
- Being unable to return early from functions makes the language feel like ass to write once you start trying to do anything complex.
- Pattern matching is meh. You're often nesting pattern matches inside pattern matches and it results in code that's a complete mess.
- Documentation is terrible and unfinished.
The first point is a fair criticism, but there's some stuff that's not included deliberately. Generally, something will only be in the stdlib if it has a consistent behaviour across Erlang and JS. Reading from stdin doesn't.
Gleam is not designed for ultimate performance - it's designed for scalability.
Lack of early return is normal for functional languages, but Gleam allows you to simulate early return with `use
It's not common to have more than one or two levels of matching. Can you show me an example?
This is a fair point - the language documentation needs work. Great opportunity for some OSS contributions😉
@IsaacHarrisHolt It must be said that performance and scalability go hand in hand.
For example, I built an ABSURDLY optimized piece of python code. As optimized as you can get before bit magic.
All this to taste a fraction of Go with the same degree of complexity.
Not everyone can afford the cloud equivalent of 2 Xeons for every project.
If python ran like go. The internet would run 90% cheaper.
No mention of Elixir ?
Elixir is great! But I like my types 😁
I use and work daily with C#, even for API stuff, and so far everything I used it for just work fine as expecting
Its not always the fault of the language but also the programmer implementing it, good working code can be written in most good languages without issues
Even on my job we use C# day in day out, software engineer here, we also use other languages but my section is purely based on C#
Totally fair! C# can be a good language for that sort of thing, but you still have to reach for external services or micro services to achieve a lot of the things you can achieve in BEAM languages like Gleam.
And you're right, you can write good code in any language. That said, some languages make it easier than others to maintain a high standard.
@IsaacHarrisHolt Sorry if that's been answered elsewhere, couldn't find, what's the color scheme and font you use in this video?
It's AstroNvim with JetBrains Mono. That said, don't just copy me :)
@@IsaacHarrisHolt Well, I'm already using JetBrains Mono, no wonder it looked familiar, so halfway there :)
Does it have pattern matching comparable to Rust’s? (Object destructuring and exhaustive enum pattern matching)
It does! Have a look at my Gleam for Impatient Devs video for more of an overview
Elixir does the same and in most cases looks the same.
But sometimes it gets annoying when You write pattern matching and think about fancy handling.
So annoying that want to return to Ruby, PHP, NodeJS unfortunately.
I'm curious what you find annoying about pattern matching?
@@IsaacHarrisHolt repetitive patterns, most of times copy pasty
You'll get that with anything though, I think
@@IsaacHarrisHolt that's question of taste - who loves patterns who loves try catches, who loves Option, Result types, somebody goes unwrap.
I'm Elixir I solved it by writing result handling function overloading and piping.
Not everyone is pattern matching lover.
That's fair, but my point is you'll always get repetitive code
Yes I really wanna see more about the concurrency APIs in Gleam, I haven't seen much.
On it!
@@IsaacHarrisHolt Thank you! I'm excited to try out Gleam to do similar tasks I've used Elixir for! I remember when Gleam first started, the project has changed alot in the past 2 years. Interesting to see the JS focus as well, almost sort of a strange choice of effort? Still not sold on that.
It makes sense, as it allows you to share types and things across the backend and frontend
the only advantage gleam has over elixir is static types. anyone that's used elixir knows it doesn't need static types. although they are working on gradual types, but you don't have to annotate them if you don't want.
Gleam's also a lot easier to learn. While Elixir is great, it does have a steep learning curve for folks who've not touched the BEAM before. Gleam makes a lot of that easier.
Also, Gleam compiles to JS, so you can run it in the browser for a full stack development experience without needing the compromises of something like LiveView (namely latency)
Love the sponsor, really cool idea. Seems more useful for experienced programmers than those leetcode style platforms.
It's great! And so much fun
Reminds me of Kotlin, but somehow without the async coloring. Something between Kotlin and Go, maybe.
I've never done Kotlin, but I keep hearing good things about it!
Nothing is better than Go for backend.
1. Everything you need is in the std library
2. Syntax is dead simple.
3. Concurrency is dead simple.
4. I’ve never written cache handler longer than 50 lines of code in Go. Having the cache as a separate process (ie redis) provides a fault tolerant system.
Go is great! I agree with your first three points for sure. On the last one, with the BEAM, your cache can be a separate process, or even on a separate node, but still be in your program, and still be perfectly fault tolerant!
exactly what I need right now?? great video!
I'm glad you found it useful!
I tried Gleam by making the usual higher-lower game but I got stuck and couldn't find in any docs how to read from stdin so I left and haven't gone back. Seems like a nice language. I'm sure I just skill issued myself hard.
The BEAM doesn't have the best story for CLI applications, honestly. That's unfortunately a limitation of the platform, given it's not what it was designed for. I'd suggest trying out a web server or some other project :)
Wrong domain! I don't think it's a con either. For compiled languages I'd say the closest functional feel language is OCaml and the closest simplicity feel language is Go for CLI software.
@@bpo217 yeah, Gleam feels a lot like a functional Go to me
@@IsaacHarrisHolt Indeed. I like the project you decided to go with btw 👍🏻
@@bpo217 Thanks!
Why not use elixir?
You could, but Gleam's type system makes it easier to have large-scale projects, and makes refactoring a lot easier.
Plus, you can use all your Elixir libs!
Man, Erlang is underrated. BEAM has gotta be one of the most impressive things I've seen
It's honestly incredible. It's a shame it's not more popular
Doesn't C# have a similar Task based API with the TPL and can handle concurrency...
Very possibly! I don't know C# well enough to comment, but the BEAM VM is hailed for concurrency and how easy it is to create distributed programs
I have one question, is the play_button / triangle ligature in your font this: "|>" ?
edited: I read the code, it seems like it is... I was confused how to make that for a moment haha
It is! Just the standard pipe. I'm just a big fan of ligatures
@@IsaacHarrisHolt Yep I've realized that it is, thanks for confirming.
No worries!
Interesting, this seems like rust except without the rough edges and running on BEAM. Ill be sure to give it a try
Please do! Let me know what you come up with
Looks interesting, I've been following Gleam development for some time now. I'm bound to try it out at some point.
For the time being though it looks like a watered down and less mature version of Scala.
Interesting take, for sure. Have a go and let me know what you think :)
I honestly don’t really get why i should switch from Go to Gleam? What are the benefits? I could get how the BEAM is more explicit with errors and more fault tolerant than e.g. goroutines
But I’ve also heard that gleam is far less performant?
You're not wrong! Gleam is less performant than Go as it's not a compiled language. However, as you said, error handling and fault tolerance are better, and it's MUCH easier to create distributed systems with the BEAM.
On top of that, Gleam's type system is much better than Go's. You don't need to worry about nil pointers, nil structs etc., and you get proper sum types rather than the error-prone kinda-enums you get in Go.
Plus, there will, at some point, be a native target for Gleam, which will improve performance (though you'd lose the BEAM).
@@IsaacHarrisHolt Oh man, guess I have to learn another new language now :D I think I was put off by Javascript being a compilation target, but I guess I can just ignore that and do stuff with Erlang.
I can't seem to find a lot of benchmarks out there, so do you know what an average performance delta there is?
I don't, but Gleam isn't really built for performance (like many BEAM langs), so I imagine it's pretty large.
@@IsaacHarrisHolt fair enough :D thanks for creating this awesome gleam content though!
No worries!
Great video! As a rust dev not convinced of gleam though. Feels like this is almost easier to implement with actix.
Plus not having to deal with the erlang VM also sounds like a great advantage to me.
Fair points. For me, I prefer not having to deal with the borrow checker, move semantics, lifetimes, and Rust async etc.. Gleam makes it much easier to deal with concurrency
just reminding, just as every tool has it's advantages, its disadvantages are equally as big
Naturally! There are always tradeoffs
Like the difference betwen Salsa on 1 and Salsa on 2 is almost impercetible to the music deaf, what makes backend so different from front end?
Very little! You can write full-stack apps in Gleam using the Lustre framework
that video had alot to unpack, too much for my brain, that's complex, grug brain can't get all of it, 50% was over my head, time to re watch this, keep this good work up
It might help to go through it slowly with the code in front of you. It's in the description :)
@@IsaacHarrisHolt will be waiting for the gleam concurrency video
Working on it!
I honestly just like Gleam for the little star guy logo
Her name is Lucy and she loves strawberry ice cream :)
What's the font and the color scheme used here? It looks exquisit and I need it.
It's JetBrains Mono and I use AstroNvim with the astrodark colour scheme.
@@IsaacHarrisHolt Thanks so much!
You're welcome!
Can you share your nvim config?
It's pretty much just the default AstroNvim config :)
Why not PureScript?
Gleam also gives you the Erlang target :)
>damn time to rewrite it all in rust
mfw gleam is written in rust
Carcinisation keeps winning
Hahaha yeah there's definitely some irony there, and it might even have been deliberate 😉
Gleam really feels like the parts of Scala that I actually liked
Interesting! Which parts would those be?
@@IsaacHarrisHolt Honestly, I think its mostly just the pattern matching, fp in a c-like syntax and the immutable data structures.
What I don't like about it is that you can write it just like Java or just like Haskell or an unholy mix of the two. I also seems to add any feature dreamed up by any PHD student into the standard language.
@@marcusrehn6915 Yeah I think that's a lot of what Gleam is trying to solve. Every feature is really thoroughly thought out before it gets added
Who is actually using Gleam in production that's notable?
How does Gleam handle unstructured data?
There are a few startups being built in Gleam, and a few Gleamlins have managed to get it into prod at their companies. I couldn't tell you who, though.
As for unstructured data, Gleam handles it like any other strongly typed language - you have to try and decode it into a Gleam type to work with it. There's _technically_ a Dynamic type, but you can't interact with Dynamic values except to decode them or just pass them around, so if you don't need to know the shape of the data at any point at all, you can just use that
Still trying to decide if I want to pick up Zig or Gleam…they’re both very compelling
I know the feeling! I wanna learn more about both databases and distributed systems, and it seems like Zig would be better for one, and Gleam the other 😅
@@IsaacHarrisHolt that's the exact dilemma I'm having. No doubt I'll find time to dabble in both, but I'd love to master something other than Go! I do love Gleams erlang roots though...agh decisions decisions!
Try them both for a while and see how far you get!
Heck yeah, Gleam!
Woo! Gleam!
OK, Do a performance benchmark then !
Comparing what? At what scale? Between which languages? What are we measuring and why is that important? What are we measuring?
It's never as simple as just "do a performance benchmark".
And why can't I just use another programming language? Rust with axum looks similar
You can use what you like! Gleam is just simpler to get started with, and Rust is famously difficult to make parallel.
@@IsaacHarrisHolt Ok, thanks for the answer :)
@@jvstbecause of course! I'm happy to help
Rust is famously difficult to make parallel??? How easy it is to parallelize complex code without introducing race conditions and stuff like that is one of it's main selling points. And with rayon, its extremely nice and easy to parallelize simple stuff. Rust certainly is not the easiest language to learn but in no world is it "famously difficult to make parallel".
@@1vader I would say writing concurrent rust code, is having the extreme benefits as well as problems of Rust. It is very hard to start but easier to master as other programming languages. Stuff like performance optimized async traits, tower services and the general Sync + Send + 'static requirement aren't easy to get right at the start. There are other languages that get you going faster, for example Go, where you can just write `go function()` to make something "parallel". Of course, rust has this concurrency model because of good reasons, but knowing them is a must to understand and work with them. In conclusion, I would say Rust can be easy for experienced users, but they are a headache for beginners and I wouldn't recommend them this approach at the begin of their rust journey.
What font are you using? :eyes:
JetBrains Mono!
@@IsaacHarrisHolt thanks!
I enjoy using fonts with ligatures but I think it’s a bad fit for informational videos
That's a fair take! I'll probably disable them in future if I remember
I don't understand the point of this video when I can do all of the mentioned stuff in C# and faster, too. Although Gleam does sound interesting worth as a side project for exploring it
Exactly what I was thinking too
I'm not familiar enough with .NET, but I do prefer writing Gleam to C#. Give it a go and let me know what you find :)
9:13 The number of battles does not increase exponentially, they increase quadratically (yes, pedantic, but I this is a comp sci video)
Totally fair! I mostly used 'exponentially' because it's the common term, but I'm aware it's not technically accurate
just use Erlang, yes I know this run on BEAM and that is why I'm saying it, just use Erlang.
By using Gleam you are kinda using Erlang, but you get the benefits of a fantastic type system too.
golang not mentioned? i wonder why...
Go did get a mention! Right at the start. I just didn't draw many comparisons because in some ways, Go is very similar. It's also one of my favourite languages, but I like Gleam for having proper sum types and no nulls :)
@@IsaacHarrisHolt okay, that's fair, my bad
No worries at all!
Bro how was the algorithm thinking ahead of me
It's almost like that's why it was made 😉
gleam can make a rest api, but cannot make a community though
What makes you say that? I'm quite active in the community and I love it
I don't understand, in what language is the equivalent code for this going to 'blow up in your face'? If the only difference is the Option type, I don't think thats a really convincing argument to switch, or even try to learn an entirely new language just for that
Any language that uses exceptions makes control flow practically invisible. You have to have some global try/catch block in your code. Gleam allows you to handle errors where they crop up
@@IsaacHarrisHolt agree with you on that. However that just makes me like go even more, it returns error as a value, and as a dev you have to make the conscious decision of ignoring an error
@@_theone_99 that's no different to Gleam or Rust, in reality. The benefit of Gleam over Go is that you have proper sum types and don't have to worry about nil, and therefore nil pointer exceptions
@IsaacHarrisHolt yep, weird decision from the creators to not have an option type. I am hopeful about sum types though, hopefully they introduce it soon.
I'll stick with Elixir.
Any particular reason? You can use Elixir libraries from Gleam, and you get the added benefits of the type system too.
@@IsaacHarrisHolt gleam threw a lot of great stuff from erlang to the trash in favor of an imperative programming style, absolutely not a fan of that.
Not having macros and/or reflection is a deal breaker to me, I tend to write nowadays a lot of declarative code that uses these feature under the hood to process the declarations. As for the types, the only rule is to validate external data, use typespecs and static tools like dialyzer to get almost the same precision in your codebase, having the added benefit to use fully dynamic values where you don't need a precise data shape.
Totally fair. You can still use all the great Erlang stuff via FFI, by the way. Things like tasks and actors just call down into Erlang under the hood
@@IsaacHarrisHolt In real-world applications this kind of complexity is not a reality. We use elixir in production because it is extremely good in terms of readability, extensibility and core libraries. Portions that need types to be checked can be covered by libraries like NimbleOptions (BTW the feature level this library has is what a good type system should look like). If elixir manages to create the static type checker, languages like gleam will be not be of much relevance in the future.
I think we can agree to disagree on this one. Also, Gleam isn't imperative. It's still a very Functional language.
my answers for the intro was elixir... but cool they bought run on Erlang
The BEAM VM is awesome, and Elixir is also a great language. I just like my types 😅
my hype dropped to the bottom when I learned that gleam doesnt have loops and forces you to use recursion instead
That's very common for functional programming languages. Most of the time you can just use the stdlib functions like fold, reduce etc.
great examples and great logic.
love this.
Thanks! I'm glad you found it useful
I wish this video spent less time writing code and more explaining why gleam is superior for this use case. The example can be built in any language. I may not be the best listener but I wasn't able to understand how Gleams special feature make it suitable as a redis replacement.
Fair criticism! As for that, the short answer Gleam has some really great ways of having in memory kv stores thanks to Erlang and the BEAM. The long answer is a little more complicated, and one for research :)
heard about DBOS cloud (or edge DB)?!
Sure, but I'm not 100% sure why they're relevant here :)
That was pretty good
Thank you!
why don't you like Scala?
I don't dislike it! I've just never used it.
@@IsaacHarrisHolt it has everything - safe types, immutability, parallelism, make your own types with wild flexibility and much more!
I'll take a look some day :)
Very Simple :tm:
> Insert Mind Cloud of Unknown Depths
Gleam is very simple! You can learn the whole thing in an afternoon 👀
I'm stubborn, so I'm still gonna write my APIs in Rust.
Totally fair! Enjoy your lifetimes :)
Gleam is great but I prefer the syntax of Roc
Totally fair! Not everyone likes the more C-style syntax
@@IsaacHarrisHolt Incidentally I'm likely to use Gleam at work whereas I don't think Roc will ever be finished! Roc is made by one of the creators of Elm, which also inspired Gleam.
@@lawrencejob Yes! I watched one of the Roc talks. It looks interesting. And do let us know if you use Gleam at work! The community would love to know what you do with it :)
This is too complicated, I'll just do it in C.
😵💫
We have 20 concurrent languages. This is stupid. We should create one that fixes all these issues as a one stop solution.
Now we have 21 concurrent languages.
This is this video.
Gleam isn't a new concurrency system, it builds on Erlang!
I don't like monolith codebases. I mean might need something to be re-written completely. What about database migration, file handling. Each language and runtime their own strength. So I'll rather use different languages and runtimes for different uses and connect all of them via pub/sub or stream.
Totally fair! My point in this video is that too many people reach for that by default. You see lots of companies running microservices when they have like, 10 users.
@@IsaacHarrisHolt Yeah that's true. I love the quote, "You shouldn't think about handling 1M users at the first place. When you have 1M users. You would love to have that problem."
Gleam seems cool, but I think I'll keep using Rust.
They're for totally different things
Update! I released a video today explaining why this comparison doesn't make sense: ua-cam.com/video/uvQL-xJWGwI/v-deo.html
0:31 you assume that rust wouldn't be my first choice for writing a backend to begin with 🤣
Yes, because it probably shouldn't be (see my video on Gleam and Rust for why!)
0:01 I would choose Elixir 🎉
Good choice! Elixir gives you a lot of the same benefits as Gleam, just without the type safety :)
Been wanting to check out Gleam more, so happy I found this channel, thanks! :)
Awesome! Let me know how you find it :)
Even Rust still doesn't have proper ecosystem. How much time would it take for Gleam to mature, huh?
And the selling points aren't there either. Awesome concurrency exists in Go and Elixir. Why would I want Gleam? I want to get things done, not be a pioneer of yet another language.
Meh.
Gleam can use Elixir and Erlang libraries, so you get the benefit of those mature ecosystems already, so no worries there.
As for why you'd use Gleam over Go, it's mostly for the type system and the BEAM. I'm a massive proponent of Go, don't get me wrong, and I love writing it. But, Gleam's type system is a lot more robust. There are no nil pointers exceptions or gotchas like that, and Gleam has proper sum types.
Give it a try and you'll see :)
Gleam compiles directly to JavaScript/Erlang. It has pretty much zero overhead over erlang so it's faster than elixir
It also has FFI compatibility with elixir and Erlang if compiling to erlang and has FFI compatibility with JavaScript if compiling to JavaScript.
There have been what feels like a million libraries to release since launch, rarely I need to do FFI but when I do it's fast syntax
@@mellowcloud6434 this is absolutely right. It compiles to Erlang which is then executed right on the VM. As to whether it's faster than Elixir, I've not done the tests. It's possible that Elixir produces more optimised bytecode at the end of the process than the Erlang that Gleam creates. It would be interesting to test.
@@mellowcloud6434 it can't be faster than elixir, both runs on same VM, are your sure it compiles down to erlang? usually beam languages put out beam binaries aka .beam file. if it does, then compilation should be slow.
I have been writing elixir for last four years, I like dynamic languages without too many type intervention, it's definitely a good to have when it comes to types. But elixir's community is so mature that everyone is nice enough to reply and write documented code. over the years I have noticed one thing with languages, the more easy you make a language to get started with, the more shit code that community generates. Look at Go, I have read so many codebases of Go, everything just abuses channels, just because compiles and works people be like okay, I'm right, not really care about quality.
nice vid isaac 👍
Thank you!
The Never ending Shoehorning of Tech World.
Shoehorning how?
Gleam reminds me so much of F#.
But with less Microsoft
@@IsaacHarrisHolt True, but F# deserves more love, really nice Syntax and Features with friendly Community.
gleam looks really nice but the standard library is really lacking, there isnt even a filesystem module (at least I couldnt find any in the docs)
There's a great library called simplifile that you can use :)
Assembly all the way 🎉
Uhhhhh good luck good luck
When you say "other programing languages" just mean node/js.
All others I know use threads (Or can use threads) just like gleam.
Nice how you just discovered the "cache" trick.... Dude, that has been done on any other language with proper threads for ages, and, check that, you can do that even with DB connections it's called connection pooling. Yeah, a pool of connections for all processes, I know ... rad, just java 1995 style...
Maan.. kids this days...
It's important to know that BEAM processes are not that same thing as threads. Most languages that allow threading will use OS threads, generally limiting you to 2x the number of cores in your machine.
Gleam processes are closer to green threads. They're very lightweight, and you can have thousands of them per machine.
I never claimed to have "discovered" keeping mutable state in another process. I was merely using it as an example of how powerful the BEAM is. Again, sure, you might be able to do this in other langs, but you'd have to have a mutex around your shared state.
@@IsaacHarrisHolt I also think that gleam is an elegant solution to most common multithreading cases. is just that you are comparing it to node and how node works. I would not say that's "most other languages" as you imply in the video. Much as the contrary, I would say that the node approach is the exception, not the norm.
I could implement this beam model (not as elegantly, sure), on any of the languages I know. I've used similar constructs in java, for example.
Not sure where you got that information, but you can have many many more OS threads than cores, (on linux, the default limit is 100k, i think, and can be expanded).
I wasn't comparing just to Node. I was using it as an example, sure, but I was actually comparing to most async/await systems, which do use an event loop. Python is the same, as is Tokio for Rust. Most of them are based on libuv or libuv-adjacent tech.
Apologies - you're right, I was getting mixed up between OS and CPU threads. Yes, you could implement a lot of this with OS threads, but again, the BEAM and its mailbox system handle things in a graceful way such that you don't have shared memory and don't have the footguns that entails.
i dont see the "simple" in gleam, i see more complex stuff like
I'm not sure how
@@IsaacHarrisHolt you did the video, you're familiar with, im not familiar with so if you are talking about something to be friendly to new devs, my opinion is more valuable than yours because this is the first time i see gleam code. first time i saw rust or go or kotlin it was very easy to understand code, its syntax and its behavior, with this gleam that didnt happened and actually those operators i mentioned were not obvious to me, that's why im saying it seems complex. python decorators are only put @yourdecorator above a function, it is very simple and that's why frameworks like fastapi or flask are so popular. in my opinion your example seems too complicated having too much verbose code in too many files instead of having something simple like fastapi endpoint based on decorated functions or an express endpoint. you might not agree with me but for me it was harder to understand than other languages i've previously seen, so this one is not "simple" to me and maybe devs with similar background i have might think in a similar way.
That's fair, but my point was that having different syntax to what you're used to does not make a language complex. It's merely something you need to learn.
And sure, using decorators in Python is simple, but I challenge you to try and recreate what FastAPI or Flask is doing under the hood. Not necessarily the whole thing, but just the decorators for registering a route. There's a lot going on there that's hidden from the user, which can make it difficult to debug etc.
Great video. I dunno why people in the comment section in this video are being so smug and obnoxious but you are taking it like a champ!
Some people take it personally when you say there is an alternative to their favorite language
Thanks! I appreciate the positivity :)
you go so fast :P
Newer videos slow things down 😅
Dotnet sticky cache monolith
Such Microsoft. Many bad.
The type safety myth... I'd love to know who these people are who need to stop themselves assigning a string to the variable `number`.
Do you know what happens to python programmers who don't use type hinting? Nothing. Because mixing up types is either a sign of gross incompetence or, far more likely, the monster lurking in the child's cupboard. You know, there one that isn't there.
If you're doing it for performance - that's perfectly valid, all power to you. If you're doing it as a crutch because you think you need your hand held - you almost certainly don't. Take those stabilisers off and just ride your bike like an adult.
This is definitely one of the comments of all time.
You come across as though you've never worked on a large project with many developers. When writing software in teams, the best thing you can do is get the computer to do as much of the work for you as possible (auto formatting, lint checks, automated testing, etc.). Type checking is part of that - it reduces the mental load on each engineer, increasing the development velocity of the team as a whole.
If you're relying on variable names to tell you their types, e.g. "number", you're basically introducing your own weak, inconsistent version of static typing anyway and creating more work for the people writing code and the people reviewing code.
There are cases where dynamic typing is helpful, for sure, but for the work that 90% of people are doing, having static types is going to be a boon purely for the time it saves debugging issues.
As much as anything else, static typing is a form of documentation. When you're onboarding new engineers onto a project, having types for them to read makes parsing the codebase infinitely easier - they don't have to keep all the context of all the types of every possible permutation of variables in their head to understand the flow of what's going on. And if you try to make the argument for documenting types in docstrings etc., again, you're using a poor-man's static typing.
On the Python point, as someone who has written a fair bit of Python professionally, and used to make Python videos on this very UA-cam channel, a lot of the industry is moving towards using type hints as much as possible. The same trend can be seen in other popular dynamically typed languages - Elixir is getting a type checker built into the compiler, and Ruby's Sorbet is growing in adoption.
Basically, all this to say... what??
I see. You're a proponent of the bloat approach. You're in a team so pile on the boilerplate and layer on the comments.
"We can't take the stabilisers off the bike dad, it'll fall over."
Let's agree to differ on that front.
Type annotations aren't bloat. Having to do more typing to make your life and your colleagues' loves easier is always worth it. Typing isn't your main job as a software engineer anyway.
@@IsaacHarrisHolt They literally are boilerplate.
Listen, we clearly have very different ideas of what constitutes good code. You're the the verbose / explicit camp, I'm in the minimalist. Some experienced coders would agree with you and competent coders would agree with me. :)
@@davidmurphy563 you're very difficult to have a constructive conversation with, by god.
Just use Scala
Scala looks cool! I've not had the chance to use it much though
@@IsaacHarrisHolt Look at Scala 3, the new braceless (python-ish) syntax is so elegant!
Is that astronvim I see 👀
It is!
And then there's me, thinking about solving your initial problem in Java Spring Boot in 20 minutes with no need for Redis or any other external service, perfectly fine error handling, exceptional stability, and clean, non-verbose code. People really overlook the "boring" languages in favor of the hottest language of the week which is more often than not made more for computers and less for humans (cough cough Rust).
Yeah, when I watch videos like this I wonder if some people ever had to deliver software to production. So much cognitive load for simple things.
@@cuca_devA big idea within ML inspired languages is that the simple things should be hard to make the complicated things easy. For an example of how this works you could watch Tsoding's video on making a JSON parser from scratch in Haskell.
I agree that Rust is probably a lot harder than it needs to be, but I disagree with you on Java's error handling. I'd much prefer errors as values to throwing exceptions.
@cuca_dev really? Writing one program is more cognitive load than deploying 10 microservices, RabbitMQ, Redis, and managing all of that? I'd prefer a single program, personally.
I think this current trend of favoring and shilling "the hottest languages" is not good for fresh juniors who's entering this industry.
There are a lot more important and basic stuffs backend devs need to know before playing with Rust, Gleam or Elixir.
I rather want juniors understand the things like SQL, POSIX commands, HTTP protocol, networking stuffs and how to write tests.
Not again!
Not what again?
Sounds like Erlang.
Gleam compiles to Erlang! So yes, it's very similar. But Gleam is statically typed, which brings a whole host of benefits around error handling and so on, as you can see
nah i can do it in go
Yep! I was just showing off Gleam :)
00:22 idk, my answer is still python :V
Valid, but you'll need redis etc.
me learing gleam bc it is a cute pink star
Lucy is the best mascot
wait how is this in any way better than rust?
It's different, honestly. Sure, the performance probably won't match Rust's, but Gleam makes it very easy to parallelise (something that Rust is famously not). You also don't have to fight the borrow checker at every turn, and the type system (which is what most people love about Rust) in Gleam is based on Rust's, so you'll feel comfortable moving.
I think they're aimed at different things. Gleam is definitely more beginner friendly, but the performance ceiling is lower
@@IsaacHarrisHoltRust's motto is literally "fearless concurrency". It's really really easy in rust.
@@vladlu6362 It's fearless, but that doesn't make it easy. It just means that you don't need to worry about race conditions etc.
gleam propaganda before gta6