5 ms·

I really came to love gleam over the last few months. I appreciate elixir getting a type system and remember that this was the big NoGo for me when I explored i

I really came to love gleam over the last few months. I appreciate elixir getting a type system and remember that this was the big NoGo for me when I explored it a while back. I'd like to give it another chance some time, but I'm worried that it's like typescript - looks typed on the outside but for many libs and packages the types are just a dynamic/any. Is my fear justified? Beam is amazing btw

throwawaymaths 11mo ago
gleam's 1/0 = 0 is crazy just because the author doesn't want there to be any raises anywhere. problem is, in many real world scenarios 0 is used as a sentinel value that doesn't "just" mean 0. iirc reading somewhere (in a non gleam system where 1/0 = 0) there was a system where everyone woke up to having zero shares because a 0 share tx was posted to everyone's trading endpoint, and a zero share tx means "zero the account".
- Hasnep 11mo ago
  I think that's less likely to happen in Gleam because using 0 as a sentinel value would be unidiomatic, but I agree that's a very dangerous design choice.
  - throwawaymaths 11mo ago
    luckily no gleam software ever has to interact with outside systems (software or otherwuse) that might make a choice unidiomatic to gleam. in case it wasnt clear: a zero share tx being a tombstone is a stock accounting convention, not a choice of that particular software project.
    - Hasnep 11mo ago
      You'd just do the same thing you do in any language, you parse the incoming data into a format that's more idiomatic, e.g. in Gleam type Record { NShares(n: Int) ZeroTheAccount() } fn parse_record(n: Int) -> Record { case n { 0 -> ZeroTheAccount() _ -> NShares(n) } } Then you don't have to worry about mixing up the two :)
      - throwawaymaths 11mo ago
        no. you're mistaken. the error came about because the code calculated shares to give out as an average over certain set of values but in the particular business cycle there were no entries to average. a divide by zero error would have crashed and either triggered review or nothing would have happened. instead, dividing by zero was happily calculated as zero and everyone got a zero share disbursement, which meant "zero all the accounts". this is not an inbound data problem. this is a scenario where if someone had programmed it in gleam, gleam would have happily calculated an (incorrect) average of zero and everyone would have lost all their shares. to wit: anything that calculates an average over non-fixed data cardinality for business logic is potentially at risk for a seroious logic error in gleam. what's worse is this is a nonobvious error. llms will likely make it a lot. a code review is likely to miss it. what's even worse is that the author refuses to acknowledge this and digs deeper in (because, well, its a "principled" choice that got made and now to change is breaking and it breaks a core "feature" of the language). 1/0 = 0 is fine for a language like idris which is used for theorem proving but never used for real world things. It's inappropriate for deploying when, for example, real money might be at stake.
        Hasnep 11mo ago
        Ah, I see my mistake. Yeah that's definitely the kind of thing that could happen in Gleam.
innocentoldguy 11mo ago
Gleam doesn't give you access to the full amazingness of OTP and BEAM. Elixir does.
- abrookewood 11mo ago
  Why? Don't they all compile down to the same AST? How does Gleam prevent the use of OTP? Honest question - not overly familiar with Gleam
  - benzible 11mo ago
    They both ultimately produce BEAM bytecode, but Gleam compiles to Erlang source first (then through the Erlang compiler), while Elixir compiles to Erlang's abstract format. Gleam doesn't prevent OTP use - it has type-safe OTP bindings, but they're less mature/feature-complete than Elixir's, plus Elixir has better BEAM runtime integration (stack traces, profiling tools, etc).
    - Blackarea 11mo ago
      Profiling tools are something that I miss a bit in gleam - yes, but otherwise I had no problems with OTP bindings. The maturity of the ecosystem is a bit lower of course. But I actually enjoy finding libraries or repos with a few hundred lines. You gotta handroll some things but that's what I am here for. ffi to erlang and js for fullstack apps is as straight forward as it gets, but erlang syntax is indeed a bit crazy. For those interested in gleam but don't want to miss some necessities: https://github.com/gleam-lang/awesome-gleam https://github.com/gleam-lang/awesome-gleam (the gleam community is super nice btw). For me some serious elixir adventure is high up in my todo list. But I remain suspicious if I can ever fully enjoy myself with a dynamic language - I think gleam and elixir do cater to different crowds. Gleam is pure minimalism (just pattern matching really), but elixir doesn't seem bloated either. I am so happy that both languages exist and give alternatives in times of hundreds of node deps for any basic slob webapp.
  - TeddyDD 11mo ago
    No REPL for example.
cies 11mo ago
Yeah Gleam. Or Kotlin on the JVM is also quite similar and has compile-to-JS if needed.
- Blackarea 11mo ago
  What? Gleam can compile to js. I don't see the similarity to kotlin being oo and all. Gleams compile time is lightyears ahead of anything on the jvm. I appreciate kotlins nullability constraints but to me it seems the jvm ecosystem is too grown to give kotlin the space it needs. Also heared that java's pattern matching and exhaustive checks have surpassed kotlins? In that case it's just easier to role with java, no?
  - cies 11mo ago
    Dunno. Wrote a lot of both. Happy with Kotlin. Grateful Java is being maintained well... My last team wanted to port all remaining Java code to Kotlin, because they just enjoyed working with it so much more. While porting I've regularly replaced 5-8 lines of Java with a single line of Kotlin. Kotlin needs Java like Ruby needs C or Elixir needs Erlang.
- lawn 11mo ago
  Elixir can also compile to JS via Hologram! Granted, it's alpha software and it's currently embedded in the Hologram framework, but still. https://hologram.page/ https://hologram.page/
cess11 11mo ago
Elixir has had types since forever, both primitive and things like structs and shape based destructuring. Then there's Dialyzer and libraries like TypedStruct. It's never been a wat-language in the style of JavaScript.
barrell 11mo ago
I would not entirely compare it to TypeScript. Due to pattern matching, legacy elixir will probably come out roughly 50% typed (extrapolating from my own usage, I'm not sure the accuracy of this number). Then since vanilla elixir is getting types (not a separate TypeElixir) I would venture anything actively maintained will get typed relatively quickly. I personally do not like type systems, and still code in JS, not TS. Any JS artifacts I produce are untyped. Yet even my Elixir-code is nearly type ready. So while TS is fighting an uphill battle, I think Elixir is working downhill.

throwawaymaths 11mo ago

gleam's 1/0 = 0 is crazy just because the author doesn't want there to be any raises anywhere. problem is, in many real world scenarios 0 is used as a sentinel value that doesn't "just" mean 0. iirc reading somewhere (in a non gleam system where 1/0 = 0) there was a system where everyone woke up to having zero shares because a 0 share tx was posted to everyone's trading endpoint, and a zero share tx means "zero the account".

Hasnep 11mo ago
I think that's less likely to happen in Gleam because using 0 as a sentinel value would be unidiomatic, but I agree that's a very dangerous design choice.
- throwawaymaths 11mo ago
  luckily no gleam software ever has to interact with outside systems (software or otherwuse) that might make a choice unidiomatic to gleam. in case it wasnt clear: a zero share tx being a tombstone is a stock accounting convention, not a choice of that particular software project.
  - Hasnep 11mo ago
    You'd just do the same thing you do in any language, you parse the incoming data into a format that's more idiomatic, e.g. in Gleam type Record { NShares(n: Int) ZeroTheAccount() } fn parse_record(n: Int) -> Record { case n { 0 -> ZeroTheAccount() _ -> NShares(n) } } Then you don't have to worry about mixing up the two :)
    - throwawaymaths 11mo ago
      no. you're mistaken. the error came about because the code calculated shares to give out as an average over certain set of values but in the particular business cycle there were no entries to average. a divide by zero error would have crashed and either triggered review or nothing would have happened. instead, dividing by zero was happily calculated as zero and everyone got a zero share disbursement, which meant "zero all the accounts". this is not an inbound data problem. this is a scenario where if someone had programmed it in gleam, gleam would have happily calculated an (incorrect) average of zero and everyone would have lost all their shares. to wit: anything that calculates an average over non-fixed data cardinality for business logic is potentially at risk for a seroious logic error in gleam. what's worse is this is a nonobvious error. llms will likely make it a lot. a code review is likely to miss it. what's even worse is that the author refuses to acknowledge this and digs deeper in (because, well, its a "principled" choice that got made and now to change is breaking and it breaks a core "feature" of the language). 1/0 = 0 is fine for a language like idris which is used for theorem proving but never used for real world things. It's inappropriate for deploying when, for example, real money might be at stake.
      - Hasnep 11mo ago
        Ah, I see my mistake. Yeah that's definitely the kind of thing that could happen in Gleam.

innocentoldguy 11mo ago

Gleam doesn't give you access to the full amazingness of OTP and BEAM. Elixir does.

abrookewood 11mo ago
Why? Don't they all compile down to the same AST? How does Gleam prevent the use of OTP? Honest question - not overly familiar with Gleam
- benzible 11mo ago
  They both ultimately produce BEAM bytecode, but Gleam compiles to Erlang source first (then through the Erlang compiler), while Elixir compiles to Erlang's abstract format. Gleam doesn't prevent OTP use - it has type-safe OTP bindings, but they're less mature/feature-complete than Elixir's, plus Elixir has better BEAM runtime integration (stack traces, profiling tools, etc).
  - Blackarea 11mo ago
    Profiling tools are something that I miss a bit in gleam - yes, but otherwise I had no problems with OTP bindings. The maturity of the ecosystem is a bit lower of course. But I actually enjoy finding libraries or repos with a few hundred lines. You gotta handroll some things but that's what I am here for. ffi to erlang and js for fullstack apps is as straight forward as it gets, but erlang syntax is indeed a bit crazy. For those interested in gleam but don't want to miss some necessities: https://github.com/gleam-lang/awesome-gleam https://github.com/gleam-lang/awesome-gleam (the gleam community is super nice btw). For me some serious elixir adventure is high up in my todo list. But I remain suspicious if I can ever fully enjoy myself with a dynamic language - I think gleam and elixir do cater to different crowds. Gleam is pure minimalism (just pattern matching really), but elixir doesn't seem bloated either. I am so happy that both languages exist and give alternatives in times of hundreds of node deps for any basic slob webapp.
- TeddyDD 11mo ago
  No REPL for example.

cies 11mo ago

Yeah Gleam. Or Kotlin on the JVM is also quite similar and has compile-to-JS if needed.

Blackarea 11mo ago
What? Gleam can compile to js. I don't see the similarity to kotlin being oo and all. Gleams compile time is lightyears ahead of anything on the jvm. I appreciate kotlins nullability constraints but to me it seems the jvm ecosystem is too grown to give kotlin the space it needs. Also heared that java's pattern matching and exhaustive checks have surpassed kotlins? In that case it's just easier to role with java, no?
- cies 11mo ago
  Dunno. Wrote a lot of both. Happy with Kotlin. Grateful Java is being maintained well... My last team wanted to port all remaining Java code to Kotlin, because they just enjoyed working with it so much more. While porting I've regularly replaced 5-8 lines of Java with a single line of Kotlin. Kotlin needs Java like Ruby needs C or Elixir needs Erlang.
lawn 11mo ago
Elixir can also compile to JS via Hologram! Granted, it's alpha software and it's currently embedded in the Hologram framework, but still. https://hologram.page/ https://hologram.page/

cess11 11mo ago

Elixir has had types since forever, both primitive and things like structs and shape based destructuring. Then there's Dialyzer and libraries like TypedStruct. It's never been a wat-language in the style of JavaScript.

barrell 11mo ago

I would not entirely compare it to TypeScript. Due to pattern matching, legacy elixir will probably come out roughly 50% typed (extrapolating from my own usage, I'm not sure the accuracy of this number). Then since vanilla elixir is getting types (not a separate TypeElixir) I would venture anything actively maintained will get typed relatively quickly. I personally do not like type systems, and still code in JS, not TS. Any JS artifacts I produce are untyped. Yet even my Elixir-code is nearly type ready. So while TS is fighting an uphill battle, I think Elixir is working downhill.