The Star Language that will outshine Rust? Gleam
Вставка
- Опубліковано 30 вер 2024
- A look at the Gleam programming language, through the lens of a Rust developer.
Keyboard: Glove80 - www.moergo.com...
Camera: Canon EOS R5 amzn.to/3CCrxzl
Monitor: Dell U4914DW 49in amzn.to/3MJV1jx
SSD for Video Editing: VectoTech Rapid 8TB amzn.to/3hXz9TM
Microphone 1: Rode NT1-A amzn.to/3vWM4gL
Microphone 2: Seinheiser 416 amzn.to/3Fkti60
Microphone Interface: Focusrite Clarett+ 2Pre amzn.to/3J5dy7S
Tripod: JOBY GorillaPod 5K amzn.to/3JaPxMA
Mouse: Razer DeathAdder amzn.to/3J9fYCf
Computer: 2021 Macbook Pro amzn.to/3J7FXtW
Lens 1: Canon RF50mm F 1.2L USM amzn.to/3qeJrX6
Lens 2: Canon RF24mm F1.8 Macro is STM Lens amzn.to/3UUs1bB
Caffeine: High Brew Cold Brew Coffee amzn.to/3hXyx0q
More Caffeine: Monster Energy Juice, Pipeline Punch amzn.to/3Czmfox
Building A Second Brain book: amzn.to/3cIShWf
Time to add 10 years of Gleam to my resume.
smart move! 🙃
I will add 11 years 😅
@@uidx-bobyou surely are an experienced hiring manager
You are hired .
Lots of recruiters ringing you tomorrow!
Bro you can't just disrespect the pipe operator |> like this. It's literally the best feature of the language.
wow, I didn't realize until this comment that I hadn't explicitly mentioned it anywhere in the video! I really like it too, thanks for pointing it out. I may mention it in a pinned comment.
@@codetothemoon |> makes your point about methods kind of redundant though, as you just replace the . with a pipe, and now it reads subject verb
Also at 4:48 the pipe operator can help you out: you can write
let excited = nums |> list.map(fn(element) {element "!"})
But you still have to specify the function explicitly, there is no particular function attached to the type (like methods are) that's why `list.` is mostly required (importing map directly would not be very readable, how would you know it's map from list module and not something else?)
@@user-uf4lf2bp8t This was my thought exactly ^
I like semicolons because it defines where stuff ends.
You obviously don’t like them that much;
4:50 ish, when using `list.map(thing, func)`, this can also be written as `thing |> list.map(func)` - this is called the pipe operator and it passes the thing before the pipe into the first argument of the method following it. You can also specify what argument it will get passed to with `func |> list.map(thing, _)` but of course it makes less sense here with list.map
ahh yes thanks for pointing this out! though i'd still prefer thing.map(func). again, maybe i'm being pedantic though :)
@@codetothemoon nah we're all just C/Java brained 😂
@@codetothemoon yeah, but i would call Gleams piping as a more general approach of the same mechanism. Rust uses the first parameter of a function to declare on which instances a function can be called on (if i remember correctly, i have little rust experience). This is something that i personally really like in imperative languages.
The default piping behaviour in Gleam is really similar but with different syntax and by using a different mechanism: partial function application. Gleams partial application also allows explicitly choosing the function argument to pipe into. So any argument could act as "the instance".
example:
fn repeat_text(text: String, amount: Int) -> String { ... }
default piping behaviour:
"foo"
|> repeat_text(4)
explicit partial application:
4
|> repeat_text("foo", _)
@@codetothemoon back to list.map(): specifying which map() function to use (map() of module list) is a huge improvement in functional languages because otherwise you would have to look up which map() is being used. It's not done by default in Haskell and it really is such a huge pain, especially in tutorials and documentation.
calling functions on instances (methods) solve the same problem. But what if an instance has multiple map() functions? How do you specify which map() to use?
dot-syntax is really really readable and i also really like rusts approach but i think gleams approach is the most general with (i think) no special cases.
I think it's worth comparing Gleam to Async Rust specifically in terms of reliability, performance (throughput and latency) and developer experience. Yes you pay a penalty for garbage collections but the BEAM brings a lot of reliability guarantees in terms of fair task scheduling to the table that you don't get with Rust, only Golang comes close. Function coloring is another big issue worth bringing into the comparison. I've been comparing Gleam, Rust, Go and Java (with virtual threads) for a new project recently. Personally I enjoyed Gleam the most, but the ecosystem isn't mature yet for what I need, so decided to use Go. Async Rust has a bunch of footguns, and it doesn't mix well with lifetimes when doing anything beyond the basics, it's easy to end up with insane compile errors, such as futures which are not Send due to some tiny thing deep down in your call stack and the errors mesages don't tell you where it is.
Thank you for making this comment so I don’t have to.
agree 💯, i would love to dive in to such a comparison
lol I am one of those guys that perfers semicolons
nice! I was surprised at how many of you there are!
I'm just guessing here, but isn't immutability usually an abstraction of the language syntax. It is great for us to reason about our code + testability, but under the hood, it will likely optimise these to avoid unnecessary operations when compiled/runtime?
i think in some cases you are correct. for example in the "field update" scenario i covered, its certainly possible that under the hood the compiler recognizes that because the original value isn't used again, it can just be updated. Not sure if Gleam specifically does this, but I don't think there are any technical obstacles precluding it. BUT I think there are more complex scenarios where the compiler simply won't be able to "optimize via mutability" under the hood. I could be wrong about this.
Currently having a blast writing Gleam. Very easy to learn language. And yeah - more gleam videos please.
Btw great video.
thank you, glad you liked it!
Elixir has an FFI package called Rustler that allows you to use Rust directly inside of Elixir. Gleam should have the same capability soon too so that you can use Rust for anything that is performance critical.
ahh nice didn't know about this, thanks for pointing it out!
@@codetothemoon yeah I’m currently using elixir and rust as my primary stack. They work amazingly together. Gleam is cool but it’s young so I can’t just move everything over from Elixir yet. Don’t feel like writing bridges to use all my elixir packages with gleam lol
@@Khari99 I really want to love Elixir, but its dynamic typing makes it impossible. It's so hard to learn a language when you need to look up documentation online for everything. With Rust, I can hit SPACE + K to bring up a function's or type's documentation in my code editor and grasp what it does almost immediately.
That's why I'm excited for Gleam. If it gets its own Phoenix, I'll use it for all my web back ends.
For a package maybe, but the devs have stated that they wont be adding native targets to the @external API, but you can still get it by binding an erlang FFI that runs a native-implemented function (in a language like rust) for almost no cost, just gotta write a lil glue.
labels being separate than internal names is actually a huge win for readability in my opinion! there's many examples in the stdlib alone that showcase how it can be useful to refer to an argument differently externally vs internally.
generally speaking, it allows you to pick an internal name that represents *how* your function is using it to perform its job (predicate, condition, filter, i've also seen `needle` and `haystack` for searching), but externally it might read nicer to say `filter(x, by: y)` (filtering x by y) rather than `filter(x, predicate: y)` (filtering x with predicate y).
for a simple function like `filter` that's not too bad, but picture a more complex function that takes more arguments and uses them in a more complex way; it might require more knowledge of how the function works internally to make sense, and be much less smooth to read in a natural way.
got it, thanks for elaborating on this! I am willing to believe that there are use cases where this feature makes a ton of sense.
Also, take note that this was cribbed from Swift, where it is used EXTENSIVELY.
@@AnthonyBullard It was pretty jarring when i first started writing swift, these days I'm not sure i can code without it.
@@MichaelFromOz I've never heard about a feature like that - but thinking about it, the params are on a different abstraction level inside or outside the function
Great video! A few things to add:
- Types are optional in function signatures, but the compiler still ensures type safety. If you want your code to specify every type explicitly, you can definitely do that, and it is usually encouraged because the compiler will provide very helpful and clear error messages (one more thing it takes from Cargo). This is very similar to Haskell, and just like Haskell it is very rare to see libraries without explicit types, since they are also a good documentation. I think the advantage of having implicit types before shipping the product is that it makes prototyping very easy, since you don't have to update all the references when you want to change a type. It would be nice to have an option to consider public functions without explicit types as warnings, though.
- The pipe operator |> wasn't covered, but it allows to chain operations like you would be able to do in Rust or something like Linq in C#. It take the left hand as the first parameter of the right hand, which I thing makes up very well for the fact that the language doesn't have methods. In your example, list.map is using the map function from the list module from the standard library, but you could have used a qualified import so you don't have to specify that map is from the list module, and it would look like nums |> map(fn(element) { element "!" })
- The use keyword, that is quite unique and powerful, wasn't covered either. It is syntactic sugar that allows to unwrap callback functions, and can be used to implement things like defer and other advanced features.
Overall, I think Gleam is a very interesting language, and definitely not vaporware: it has reached v1 so we will likely not see breaking changes soon, and with its access to the Erlang and JS ecosystems, it can be used for a lot of things. It is a high level language though, so it won't replace Rust's capabilities as a system language.
Gleam is like a functional version of Go.
hmmm sort of, but i think that might be an oversimplification
But not as fast as Go
@@codetothemoon the author, Louis, describes it as "functional Go". but its deff an over-simplification. he just means that its a small, simple, opinionated, easy to learn functional language
@@SnowDaemonGleam was originally supposed to have Haskell-like ML syntax but the author felt that it was not as popular lol.
5:58 if the types can be infered by the compiler, then they can be infered by a linter and just added to your code automatically. That should be the play here.
yeah, definitely a viable approach for those who prefer explicit types!
Yeah I used to dislike semicolons just like you. But then I’ve had my fair share of confusing errors where the compiler couldn’t infer where a line ends, and now I prefer mandatory semicolons. They give more freedom and precision at a tiny price.
I can understand this perspective!
I don't think Gleam competes with Rust, more with Go. But I don't see why not just use Go instead. Perhaps if you like to leverage the nice actor tools of Erlang?
I agree it seems like it caters more to the things you'd use Go for as opposed to Rust. But the syntax borrows (no pun intended) so much from Rust that it's hard to avoid the comparison. I think the main reason why you'd choose it over Go is if you prefer the pure functional approach and the "next level" type inference
error handling is the biggest weakness of Go
it doesnt help me to avoid errors
Rust was not built for concurrency. Gleam will outshine rust and several other languages because of the BEAM
@@perc-ai The BEAM is a double edges sword. For server, sure, it's nice. But if you want to write something to ship to the users, it's a big deal having them install a VM just to run your app.
I'd say it competes with Elixir more than anything else.
i prefer semicolons
nice - there are definitely more of you than I thought there would be!
Interesting take to compare Gleam to Rust.
It helps to know that Gleam runs on BEAM, which is like JVM for Erlang - lots of the weird parts you mentioned are obvious for someone who knows Erlang/Elixir. Also basing a language on BEAM means that it will have way easier adoption, like Clojure or Scala which didn't have to work from scratch. Last but not least BEAM has actor-based concurrency model which is OP in many practical cases.
Yeah, though AFAIK, Gleam's OTP library is still bare-bones compared to Elixir.
@@verified_tinker1818 good point, but what about just calling Elixir from Gleam? I mean it's no silver bullet, but is it useable? Or is it unwieldy (I imagine it might be similar to working with untyped actors in Scala, I did this like 8 yrs ago and it was horrible)
i'm unsure why is gleam always compared to rust. gleam's a functional garbage collected language at its core, what common does it have with rust? wouldn't it better to compare it with elixir/ocaml/clojure/other functional languages?
Maybe. I suspect they are compared because many of the more "superficial" aspects of the syntax are similar, such as many of the keywords. But as you say, they are really quite different under the hood.
I don't think Gleam's aiming to replace Rust, but more "mainstream server languages" like go, python, java, js, etc
I agree. the syntax is so similar to Rust that it's hard to avoid the comparison. Also, the fact that it can be used in lieu of JS for full stack web development also makes the Rust comparison relevant.
Gleam is basically Rusty Elixir.
I don't know if I like Gleam...
Doesn't matter anyway, because I am making my own compiled language already. Remember kids, lexers are a pain in the ass to make well.
Gleam; the language for the lazy coder coming from Javascript that cannot be bothered learning Rust.
There - the video in one line.
Hah, that's one way to look at it!
yeah rust is dead, time to add gleam to linux kelner :3
hah!
Look into “use” - you can use it to emulate ? In Rust, early returns, defer in Go and Zig, and lots of other cool things.
Hey, you only talked about syntax. Surely the whole point of Gleam is that. it runs on the Erlang Abstract Machine and hence makes distributing ones application over thousands of real computers in a fault tolerant way very much easier than in a language like Rust. A killer feature if you are wanting to crate a huge distributed system.
I prefer semicolons;
nice, this perspective is turning out to be far more common than i thought it would be!
5:40 the Rust LSP (rust analyzer) has a shortcut to explicitly show inferred types. Maybe the Gleam LSP will have that too?
I love, love, love labeled arguments. It makes for code that reads almost like natural language.
```
pub fn replace(inside string, each pattern, with replacement) {
go(string, pattern, replacement)
}
replace(each: ",", with: " ", inside: "A,B,C")
```
whoa, actually this is the first example i've seen that has done it for me in terms of showing the value. I think I kind of get it now!
I hate type inferrence in parameter lists. I want this to be explicit so I know what it's designed to take and do.
understandable - I suspect many folks agree with you!
The good thing is that you can explicitly declare your parameter types, there are plenty of examples in this video. And so far, I haven't found a library that isn't well enough documented on the types to use for everything.
@@Varpie Sure, but behavior changes depending on the implementation. For example, if it's gonna use iterators versus arrays, it would be nice to be clear and constrain that type to enforce arrays, if you want best performance.
Otherwise, the compiler must infer type constraints from the implementation, and that might be looser than they expect, limiting API changes.
@@Christobanistan Gleam is a statically typed language that doesn't have polymorphism or interfaces, so the only way you can have a function that can be used for either iterators or arrays is with generics. In that case, the decision would be the caller's responsibility, which makes sense to me. Unless I'm missing something, in which case I'd like to have an example, because type inference still requires to have a type defined somewhere and the compiler will give a nice error if it doesn't fit.
"Can't do that in Rust." Rust has macros, so if it's really desirable, you will be able to do so with a library. It won't need to be a language feature.
true!
I prefer semicolons just like I prefer having periods at the end sentences I read.
I can definitely see that - there are more folks with this stance than I thought there would be!
R user here, fun seeing the pipe operator in another language. Makes functional programming so much more intuitive for me to be honestly
I agree, the pipe operator is great. So sad i forgot to explicitly mention it in the video...
You can find the pipe operator in julia too.
@@guelakais1438 And F# and Elixir
that pipe syntax comes from Erlang IIRC, it's not from R nor Julia, and it makes sense that Gleam has it since it basically is an Elixir variation
Thanks so much for this video! I prefer semi-colons myself, even after dealing with languages that didn't require it earlier in my programming career (VBA). There's something so comfortable about explicitly defining where stuff ends.
Thanks for watching! so many more people that prefer semicolons than I thought there would be!
The thing that really impressed me with Gleam is that the most succinct, "Gleamy" solution seems to also be the most readable - I am still mildly traumatised by my first year undergraduate C programming teacher who used to write every single program on a single line, brackets and all - so although Gleam currently isn't quite suitable for my current use cases, I'm definitely keeping an eye on it.
I like semicolons
there are so many of you! 🙃
WHAT ARE YOU TALKING ABOUT????? "C++ will outshine Erlang". FUCK NO, IT"S TWO DIFFERENT CATEGORIES!
Yes, as I mention in the video they are actually very different. But they can still be compared.
Rust and gleam are two completely different language with different purposes.
Do not try to compare or oppose them. This is foolish.
You could say they are apples and oranges. Which can still be compared :)
The main reason for the comparison is that most of my audience is interested in Rust, so it provides a common base.
Gleam used to have a record type but moved to the single custom type to make the language surface area. I really liked the record types but I can also aprecate the Golang style simplicity overall.
oh interesting I didn't realize this!
It's probably unfit for CLI because Beam takes like half a second to launch. CLI might be the only use case where the most important factor is first-pass performance, and Beam languages are even worse at this than Java.
maybe you're right!
I prefer semicolons. And im a python dev...
Gleam is great tho
whoa interesting! ooc why do you prefer them?
@@codetothemoon I like when different "pieces of code" have very clear boundaries.
A great example would be braces for denoting code blocks. In brace-based languages I can copy-paste anything with whatever indentation (as long as it's ends up inside braces) and then run auto-formatter and the code would look nice. In python it is not as easy because indentation effects AST, and I have to manually fix indentation, and only then I can run auto-format.
Semi / no semi - pretty much the same but to lesser extent. What if I get a snippet consisting of multiple statements, but for whatever reason it's all one line (maybe someone can't use slack properly idk). If statements are separated with a semi - auto-format would fix it in a sec. Whitespace characters are easier to lose.
If you want something like gleam without GC, you can have a look at Roc, though it's at rather early stage and the syntax is more Haskell like.
Thanks, I have Roc on my "to check out" list!
They made SCALA once again
the inferred param types and inferred generics sounds like a pain to review. In rust a majority of the time you can tell what a function does just by looking at its signature.
yeah, a case could definitely be made for this. In teams I can definitely see guidelines being established to require developers to be explicit about types, if only for the purpose of making code reviews easier
One difference between Gleam/Rust is the use of Option
- Rust uses it for any nilable value
- Gleam wants you to use Option for things like optional function params, and use Result for function returns. Eg: `list.find` will return `Result(a, Nil)`
and what exactly is the difference?.. Options and Results are used in the same way in both Gleam and Rust
@@sunofabeach9424 That is incorrect -- given the function `find` for an iterable, an idiomatic Rust function would return `Option`, while an idiomatic Gleam function would return `Result(a, Nil)`.
Gleam uses `Option` to denote _optional inputs_, while Rust uses `Option` to denote any nullable value.
In the language tour, they state this:
tour.gleam.run/standard-library/option-module/
@@jly_dev ah so result is mostly semantic?
@@sunofabeach9424 basically Result is an Option but with a generic type instead of the "None". So you can have Result where E is the error type, maybe just a String, maybe your custom Error type
It might not be as straight forward but in Rust you can pattern match a string like so:
fn process_message(input: &str) -> String {
match input.split_whitespace().collect::().as_slice()
{
["Assistant:", other @ ..] => other.join(" ").to_string(),
_ => "other cases".to_string()
}
}
Thanks. I hate it.
babe wake up another useless language that doesn't solve any interesting problems just dropped
I don't think languages can be evaluated in such binary terms - ie "they solve a problem or they don't". Things are more fluid than that - some languages may be a better fit for some domains but worse for others, all in varying degrees. And sometimes the reasons for the good or bad fit can be deep in the nuances of the language, as opposed to being obvious on the surface.
Please cover Lustre, and real-world use-cases for Erlang/Elixir interop!
thanks, maybe I will!
You could also destructure strings in Erlang / Elixir. Even bit streams.
ahh thanks for pointing this out! destructuring is so nice
The thing with immutability is more complex. Just because the compiler doesn't allow mutability doesn't mean the compiled code doesn't mutate anything to improve performance. In fact, FP devs came up with multiple patterns solving immutability problem: most notably persistent data structures.
No loops aren't the biggest turnoff
It's basically F# but with better tooling (at the time of writing).
thanks for pointing this out, I haven't actually tried F#!
Luster yes please
nice, i have it on my video idea list!
I love rust, but gleam looks like a better choice for web development.
maybe once the ecosystem matures a bit!
i learnt programming on C. i cant live without a semicolon;
Definitely more semicolon fans than I thought there would be!
Like to also mention that Gleam is written in Rust.
I like it. I think it will potentially eat into erlang and elixer.
I'm waiting for the day people stop writing f*%king Java and JS.
Both those languages need to die.
hah! I find this position relatable. I was a Java fanboy for so long....
5:28 I've seen another language with static inferred typing for function signatures: Scopes
hadn't heard of Scopes - thanks for putting it on my radar!
@@codetothemoon I guess I've been the only serious user of scopes for one or two years besides the creator.
It's the most powerful low level programming language with the best features of various programming languages (Rust, C, C++, Lua, Python, Lisp, ...).
If it was a little more like Rust, I would probably use this language.
It doesn't have a proper borrow checker yet (the algorithm works the same, but it doesn't support struct fields to have a lifetime).
And there are no orphan rules. It's possible to define the same method for the same type in different libraries.
I use Elixir a lot, more for the BEAM than the language. BEAM is incredible. What's interesting is that you can interop rust code with the BEAM and if you're using gleam that might make things quite interesting from a dev point of view since the syntax is similar (or more confusing) not sure.
what do you value most in the beam ecosystem that you feel like you can't get elsewhere?
@@codetothemoon High availability was the fundamental design goal of the vm. You get it almost for free by just using its language. There's a lot to unpack there but that's what I value most. This can be achieved elsewhere but it's way more complex and difficult to get right.
I'd love to see a video where you explore some of that through gleam or elixir.
gleam's syntax is actually Rust without semicolon
Ok, so yet another comparison of a motorcycle versus a sun cream. One is more red but the other one comes with a selection of scents. Both can be applied to one's balls. I can't decide which one i like more....
perfect analogy! 🏍️
Internal names versus external names is definitely bloat.
interestingly, I think you might be the first I've heard that agrees with me. there have been many comments defending this feature 😎
I think comparing Gleam to Rust, is like comparing apples to oranges.
I agree. It makes sense to compare them in some ways, and not in other ways 😎
gleams logo made me think it was another js framework
Understandable given that there are about 10 new ones per day!
I wish rust had the pipe operator, gleam is such a fun and interesting language despite a handful of things I have mixed feelings about.
re: pipe operator, me too. and i'm on the same page regarding your general sentiment of Gleam!
Unfortunately, I don't like gleam's type system at all. I often use self-implemented structs and enums in my programmes and am always very disappointed when I don't find them in a programming language.
it has GC and no loops, i feel clickbaited.
definitely can relate to the GC aversion. I personally like the absence of loops though :)
yes to labelled arguments. `dismiss(view, false)` bad. `dismiss(view, animated = false)` good. wherever you’re viewing that code.
yeah i agree in a code review context where you might not necessarily have the inline help of an ide, i agree this is preferable! makes me wonder if we should strive for code review tools to have the same goodies that ides do
@@codetothemoon while better tooling is always a win, ordinary struct literals already require field names. so why shouldn’t functions get to have the *option* of requiring argument names? what even is a struct literal if not a funky looking function from which all instances of it originate anyway?
I've had unpleasant experiences with things like adding an optional boolean parameter to a function, while someone else, on a different branch, added a different optional boolean parameter to the same function and then after merging, some calls to the function accidentally specified a value for the wrong parameter. Labelled arguments could have prevented that.
5:02 your objection here is solved by the pipe operator |>. Also it's worth pointing out that ocaml handles generic types the same way. And that Gleam runs on the BEAM. So garbage collection isn't as obstructive. I would have though that Rust was for low level stuff, competing with C/C++, while Gleam was for stuff like highly concurrent services, competing with high level languages.
I just dabbled in Gleam, and it's like a mini vacation from rust or js. From top down, you can teach this to kids, without diving deep. Step by step, learn more, very Pascal-ish in nature, except functional piping. I was very happy to scope it out. It deserves good book on deep concepts. I had to dig into the library and examples. It does look made for wasm, so I need to try that.
The name parameter stuff is actually more than something an IDE could do. The goal is that if you need to modify/add/swap arguments of a function, it is simpler to maintain in the rest of the codebase. When you have two parameters, its easy, but when you have 8 parameters to a function, 4 of them have the same type and you need to remove the 5th one, the process is error prone and/or confusing. Sometimes, being explicit about parameters can be a good thing.
It also allows people who like different things to live in the same codebase. Think of the myFunction(src, dest) vs myFunction(dest, src), both of these ways are valid and maybe you prefer writing one way and your coworker another, with name arguments, each one can do his thing in a non ambiguous way
isnt a VM Language more of a competitor to Java/C# . Why are we comparing it to a Memory Controlling, compiled Language?
By the By i put Semicolons in TS/JS. I like semicolons :D
I think not touching on the BEAM and the Erlang/OTP runtime and ecosystem that come with it really misses the point of the language.
maybe. I thought the syntax was interesting irrespective of any performance / concurrency / reliability narratives. I also don't yet have a good handle on BEAM yet, so that's also a factor. I think I understand the historical significance of it, but I am still trying to fully understand what it brings to the table today that you can't get in other language ecosystems.
@@codetothemoon it’s a true actor system, which means communication happens via message passing which is more generally useful than channels. It is distributed concurrency as well. And also live patching of a running system.
It also provides a built in in-memory key value store, patterns for robust concurrency battle tested in high-availability telecom switches, and more.
7:51 this feature is supposed to be how you define Algebraic Data Types. In this case, Thing is a type that has 3 constructors. The power of Algebraic Data Types is when they are recursive, unlocking a very elegant style of functional programming.
Gleam doesn't support recursive types does it?
@@samuraijosh1595
The following compiles in Gleam:
import gleam/io
pub type Nat {
S (t: Nat)
O
}
pub fn main(){
io.debug(count(S(S(S(O)))))
}
pub fn count(n: Nat) {
case n {
S (t) -> 1 + count ( t)
O -> 0
}
}
Yes, I actually prefer semicolons. And my first language didn't have any, so it's not a bias from that. It can avoid some issues and imho is better than escaping newlines like in Python.
Regarding mutability & efficiency, there are languages which do not support mutability in the code but will make values mutable during compilation for optimizations, the best of both worlds basically. Not sure if Gleam can do that, though.
Semicolons (like C or Rust) or periods (like Erlang or Prolog) are a good thing. Determining when a statement ends must happen, and letting a compiler or interpreter do it insted of having explicit control of it feels wrong, and I have seen it lead to terrible surprises.
i think gleam does it by detecting when an expression ends which is much easier in gleam because it mostly just has functions.
@@Ryuu-kun98 It's not easier. We'll eventually see a problem from it, even if we don't know that the problem was written in Gleam.
Rust is painful to read and understand, for me. C++ is usually much easier. C++ can get crazy, especially modern C++ but most code isn't like that. Maybe it's just what I'm used to.
Good interaction baiting on the semicolons! Well done! :)
thanks, but fwiw I was genuinely curious about it. i had been thinking of semicolons as potentially being a remnant of an old approach to programming that was now of dubious value, but the number of people saying they prefer semicolons is making me question that
can you take a look at Roc? it looks very innovative but it is quite young
it does look really interesting, i've put it on my potential video idea list!
All you talk about is syntax sugar
I have a sweet tooth what can i say! 🙃
I posted smth dumb about there being inferred types in nim and go but realized you meant inferred types in function params. Yeah I've not seen many langs with such features. Personally idm it, but when I did Haskell for my fp class I put the types for the function anyway to aid readability.
yeah i think explicit types are definitely warranted in some cases
if you lived in a world with mostly semi colon your gonna prefer semi colons.. to me it cause more problems as much as loops. thats why i like sql over mongodb style of querying.
BEAM VM ... just saying.
good thing or bad thing?
I'd love to see a video on Lustre
Thanks for letting me know, I'd love to make one at some point!
7:00 I would go one step further. I think there should only be structs in a language. And some are callable.
So you can create an argument list and store it somewhere before actually calling it.
The lack of types in function signatures is fine in private functions but inexcusable in public functions. IMHO
I prefer semicolons
there are more of you than I thought there would be! I can definitely see the value in semicolons, despite having a slight preference for going without them
You lost me on “it runs on a virtual machine”!
yeah, probably not a popular thing for fans of Rust 🙃
I don't understand the comparison to Rust. Gleam seems to play on a different field, especially being a GC language. And there are sooo many proven languages there, that I don't know why we should do it again, when ergonomic non-gc memory safety is on the horizon (I'm saying that because Rust leaves some things to be desired, and might or might not solve them before another language solves them).
I agree it does play on a different field. I think such a comparison is warranted for four reasons
1. The fact that Gleam compiles to JS means it may emerge as another viable alternative for full stack web development, as Rust has due to WASM
2. The Gleam syntax is heavily inspired by Rust
3. Those who are interested in Rust are often interested in bleeding edge languages, so assuming Rust as a point of reference when taking a first look at Gleam may be helpful
4. I make lots of Rust content, so subscribers are more likely to be familiar with Rust
@@codetothemoon Thank you for such a swift reply, and I apologize for my harsh tone. I'd also suggest to keep your eyes on June language, cocreated by Sophia Turner, who has had extensive participation in both the TypeScript and the Rust team (and is also the creator of Nushell)
6:45 and for functions with a lot of params with default values it lets you specify the ones further back in the order without enumerating each param that comes before
REEEEEEEEEE Rust 4 lyfe!
🦀
Python + Rust = Gleam?
Python + Rust = Mojo!
C++ gang here forever!
I've heard that some of the recent additions to the language are great!
Loved the video. Really excited about Gleam but I am tired of Rust people being Rust people. The ending statement just seemed unnecessary and just shows incredible bias. I love Rust, but not in the same way you Rust people do. It's a whole another level.
thank you! yes, the ending statement is based on my personal tastes. what would your ideal language be? is it something that already exists?
Eventually everyone will discover Lisp and realize they got it right in the 50s
You grew beard
I did!
Not a chance..it is not in the same category as rust..this is for web dev..
i agree that it's not in the same category as Rust, but I'd dispute that it is limited to web dev
how does it deal with stack management if there are no loops and you can only do recursion?
it has tail call optimisation
The compiler optimizes recursive iteration to normal while/for-like looping under the hood wherever possible. Just like Haskell.
the last "opinion" at the end doesn't make sense and is a misunderstanding of ownership semantics, they are not incompatible with a garbage collector. It's not either or. In rust you're forced to "naively" reference count, or resort to more esoteric strategies to manage heap allocations with non-obvious lifetimes (which is the point of a garbage collector), if you could just stack allocate everything and track DAG lifetimes with ownership life would be simpler, but this doesn't apply to all algorithms or data structures. Hence that linkedlist in gleam is "simple" to write, but in rust requires you to read a book.
man I need to stop getting these kinds of recommendations, bad youtube algorithm bad.
Haha imagine showing that little girls logo to a client. This is the language I’m using 😂
right before you inform them that their webapp needs a bit more css glitter 🪄
imagine showing a logo to a client...
were programmers bro, not marketing agents. focus on what important here 🤣
@@SnowDaemon haha that’s disconnection from reality. We are all marketers baby 😄
You know I woke up this morning thinking, "Man... if only we had just one more programming language"
we also don't have nearly enough reactive javascript frameworks!
No.
Definitely not for everyone!
wish it wasn't political
the community around the language you mean?
@@codetothemoon the ones who run their website
F sharp. Or c# without loops and classes.
Useless stuff. The key of each lang is an idea of usage and not the lang features. Taken
Rust, spoiled its main idea with gc to achieve what?
The main goal is a type-safe language for the BEAM-Ecosystem