Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Gleam Programming Language

gleam.run

Post reply on HN
Print view View original

121–130 of 189 posts

Re: The Gleam Programming Language

#121

Post by onlyrealcuzzo »

akanapuli wrote: post #118

I am really interested in whether anyone has evaluated the performance of Gleam? The language is simple, easy to understand, like `Go` for example, but is it really performant like Go, or does it have any performance cost since it runs on top of a VM?

I'm working on a similar language.

The facts about Gleam:

1. It runs on the BEAM - exceptionally slow compared to Go, but infinitely scalable by default in a way that Go is not - in practice, very rarely matters.

2. They will argue the slowness doesn't matter -> if ~97% of time is spent waiting on I/O -> you can be 10x slower and that means you're only ~30% for typical applications -> it's easier to scale more machines on the BEAM than it is to scale a single machine -> this is true, but largely irrelevant in Go's core market -> it's almost as if Go was built by smart people.

3. The reality is that predictability is much harder to guarantee once you start moving components to different machines. Correct, predictable distributed computing makes correct, predictable concurrent programming look easy.

4. The BEAM does not allow shared memory, Go does (unsafely). There are many cases where the performance impact of this is night and day (why Go ultimately allowed unsafety).

I assume Gleam claims to make this just work. But as someone working in this space, this seems like trying to abstract away the difference between taking a boat to Europe or a plane.

Gleam may be nice if you're building something for the BEAM (massively scalable single app that just makes sense with the actor model, typically chat / telecom).

Though I question why you would use it over Elixir.

Go's syntax kind of blows, but it is so INCREDIBLY good at what it does, that you are not going to beat Go by just having better syntax and being "infinitely scalable" by default.

In practice, Go is easily scalable enough for almost anyone. If it isn't congrats, you're a $10B+ company. You can afford to rearchitect and optimize your hot paths.

Re: The Gleam Programming Language

#122

Post by [deleted] »

okkdev wrote: post #61
librasteve wrote: post #37

thought I’d try the showcase example in Raku ( https://raku.org ), so this Gleam import gleam/io pub fn main() { io.println("hello, friend!") } becomes this Raku say “hello, friend!” well maybe you really want to have a main() so you can pass in name from the command line #!/usr/bin/env raku sub MAIN($name) { say "hello, $name!” }

Raku looks sweet, but what is the point of this comparison? :)

[deleted]

Re: The Gleam Programming Language

#123

Post by librasteve »

librasteve wrote: post #120
tasuki wrote: post #108

Earlier quoted context omitted.

> But I get the feeling that Raku is underappreciated / dismissed by many due to the perl5 / perl6 history. Yes that would be me! If you like making these comparisons, can you write the following pattern matching in Raku? import gleam/io pub type Fish { Starfish(name: String, favourite_colour: String) Jellyfish(name: String, jiggly: Bool) } pub fn main() { handle_fish(Starfish("Lucy", "Pink")) } fn handle_fish(fish:…

sure... role Fish { has Str $.name } class Starfish does Fish { has Str $.favourite-colour; } class Jellyfish does Fish { has Bool $.jiggly } sub handle-fish(Fish $fish) { given $fish { when Starfish { say .favourite-colour } when Jellyfish { say .name } } } handle-fish Starfish.new: :name("Lucy"), :favourite-colour("Pink"); I would probably reach for multi-dispatch... role Fish { has Str $.name } class Starfish does…

Here's the other Gleam concurrency example in Raku for good measure:

  my @promises;

  sub MAIN() {
    # Run loads of green threads, no problem
    for ^200_000 {
      spawn-greeter($++);
    }

    await Promise.allof(@promises);
  }

  sub spawn-greeter($i) {
    @promises.push: start {
      say "Hello from $i";
    }
  }

Re: The Gleam Programming Language

#124

Post by eyelidlessness »

tombert wrote: post #17
eyelidlessness wrote: post #15

Earlier quoted context omitted.

> But let’s dissect that last suggestion; suppose I do modify the type to encode that. Suddenly pretty much every field more or less just because Maybe/Optional. Once everything is Optional, you don’t really have a “type” anymore, you have a a runtime check of the type everywhere. This isn’t radically different than regular dynamic typing. Of course it’s different. You have a type that accurately reflects your domain…

No, it really isn’t that different. If I had a dynamic type system I would have to null check everything. If I have declare everything as a Maybe, I would have to null check everything. For things that are invariants, that’s also trivial to check against with `if(!isValid(obj)) throw Error`.

The point of a type system isn’t ever that you don’t have to check the things that make a value represent the type you intend to assign it. The point is to encode precisely the things that you need to be true for that assignment to succeed correctly. If everything is in fact modeled as an Option, then yes you have to check each thing for Some before accessing its value.

The type is a way to communicate (to the compiler, to other devs, to future you) that those are the expected invariants.

The check for invariants is trivial as you say. The value of types is in expressing what those invariants are in the first place.

Re: The Gleam Programming Language

#125

Post by systems »

replwoacause wrote: post #98
wiskiy wrote: post #31

I am in love with Gleam! As a young computer science student, I found that Gleam brought back the joy of programming just when I felt like I was seriously burning out. I was never a fan of functional programming languages. I had tried other BEAM languages like Elixir and Erlang before, but Gleam is the one I’ve enjoyed the most :)

Have you tried F#? That usually gets a lot of praise in FP discussions.

F# seem to be in abandon-ware state the creator of F# moved to another job as his primary work the forum and community are very dry

Nothing interesting being created in F#

As much as I had high hopes for F# I think its safe at this point, to not pursuit it any further

.Net is C#

If you want an Ocaml like language, that is not Ocaml, your best bet is Rescript and that being said, Rescript is probably more of a competitor to gleam, since gleam also have javascript as a target

Re: The Gleam Programming Language

#127

Post by tombert »

LinXitoW wrote: post #67
tombert wrote: post #13

Earlier quoted context omitted.

I know everything reduces to bits eventually, but modern CPUs and memory aren’t as “lossy” as the network is, meaning you can make more assumptions about the data being and staying intact (especially if you have ECC). Once you add distribution you have to encode for the fact that the network is terrible. You absolutely can parse at ingress, but then there are issues with that. If the data you got is 3/4 good, but one…

But your program HAS to have some invariants. If those are not held, simply reject all the data! What the hell is really the alternative here? Do you just pretend your process can accept any kind of data, and just never do anything with it?? If you need an integer and you get a string, you just don't work. This has nothing to do with types. There's no solution here, it's just no thank you, error, panic, 500.

You handle that in the validation layer, like millions of people have done with dynamic languages in the past.

Re: The Gleam Programming Language

#128

Post by threethirtytwo »

nesarkvechnep wrote: post #48
krainboltgreene wrote: post #40

Earlier quoted context omitted.

IMHO this is an education problem.

Problem which plagues 90% of the people? How to overcome it?

It's an education problem on two fronts. People inside the ecosystem need to know about it. And also people too deep in the elixir ecosystem who don't know how ad-hoc polymorphism is supposed to be used in a statically typed language.

Both overcome it by admitting they don't know and need to learn.

Re: The Gleam Programming Language

#129

Post by tombert »

phplovesong wrote: post #45
tombert wrote: post #8

I remember playing with Alpaca a few years ago, and it was fun though I didn’t find the resulting code to significantly less error-prone than when I wrote regular Erlang. It’s inelegant, but I find that Erlang’s quasi-runtime-typing with pattern matching gets you pretty far and it falls into Erlang’s “let it crash” philosophy nicely. Honestly, and I realize that this might get me a bit of flack here and that’s obviou…

You seem to have a fundamental misunderstanding about type systems. Most (the best?) typesystems are erased. This means they only have meaning "on compile time", and makes sure your code is sound and preferrably without UB. The "its only bits" thing makes no sense in the world of types. In the end its machine code, that humans never (in practice) write or read.

I know, but a type system works by encoding what you want the data to do. Types are a metaphor, and their utility is only as good as how well the metaphor holds.

Within a single computer that’s easy because a single computer is generally well behaved and you’re not going to lose data and so yeah your type assumptions hold.

When you add distribution you cannot make as many assumptions, and as such you encode that into the type with a bunch of optionals. Once you have gotten everything into optionals, you’re effectively doing the same checks you’d be doing with a dynamic language everywhere anyway.

I feel like at that point, the types stop buying you very much, and your code doesn’t end up looking or acting significantly different than the equivalent dynamic code, and at that point I feel like the types are just noise.

I like HM type systems, I have written many applications in Haskell and Rust and F#, so it’s not like I think type systems are bad in general or anything. I just don’t think HM type systems encode this kind of uncertainty nicely.

Re: The Gleam Programming Language

#130

Post by tombert »

folex wrote: post #49
tombert wrote: post #26

Earlier quoted context omitted.

With all due respect, you really do not understand these protocols if you think “just use TCP and ECC” addresses my complaints. Again, it’s not that I have an issue with static types “not protecting you”, I am saying that you have to encode for this uncertainty regardless of the language you use. The way you typically encode for that uncertainty is to use an algebraic data type like Maybe or Optional. Checking agains…

> ends up being the same checks you would be doing with a dynamic language Sure thing. Unless dev forgets to do (some of) these checks, or some code downstream changes and upstream checks become gibberish or insufficient.

I know everyone says that this is a huge issue, and I am sure you can point to an example, but I haven’t found that types prevented a lot of issues like this any better than something like Erlang’s assertion-based system.
Post reply on HN