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

innocentoldguy 1y ago
Gleam doesn't give you access to the full amazingness of OTP and BEAM. Elixir does.
- abrookewood 1y 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 1y 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 1y 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 1y ago
    No REPL for example.
    - Blackarea 1y ago
      Oh really a compiled strong and statically typed Language doesn't have a repl? How come?
      - aryonoco 1y ago
        I mean, it’s not impossible. F# is a compiled, strongly and static typed functional language that also provides a great REPL
  - rkangel 1y ago
    When talking about Elixir (or Erlang) you are actually talking about two things that give you the value: - A language (Elixir/Erlang) and runtime (BEAM) - The concurrency standard library (OTP) The language and runtime give you the low level concurrency primitives - spawn a process, send a message etc. But to build actual applications, you rarely use those primitives directly - instead you use GenServers and supervisors. That gives yo a way to manage state, turns message passing into function calls, restarts things when they crash etc. Gleam compiles to the same runtime, but doesn't provide OTP in the same way - static types aren't easy to make work with the freely message passing world of OTP. They are implementing a lot of the same concepts, but that's work that Gleam has to do. (Elixir provides some thin API wrappers over the Erlang OTP APIs, and then also provides some additional capabilities like Tasks).
cies 1y ago
Yeah Gleam. Or Kotlin on the JVM is also quite similar and has compile-to-JS if needed.
- Blackarea 1y 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 1y 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 1y 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 1y 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 1y 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 1y 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.

innocentoldguy 1y ago

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

abrookewood 1y 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 1y 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 1y 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 1y ago
  No REPL for example.
  - Blackarea 1y ago
    Oh really a compiled strong and statically typed Language doesn't have a repl? How come?
    - aryonoco 1y ago
      I mean, it’s not impossible. F# is a compiled, strongly and static typed functional language that also provides a great REPL
- rkangel 1y ago
  When talking about Elixir (or Erlang) you are actually talking about two things that give you the value: - A language (Elixir/Erlang) and runtime (BEAM) - The concurrency standard library (OTP) The language and runtime give you the low level concurrency primitives - spawn a process, send a message etc. But to build actual applications, you rarely use those primitives directly - instead you use GenServers and supervisors. That gives yo a way to manage state, turns message passing into function calls, restarts things when they crash etc. Gleam compiles to the same runtime, but doesn't provide OTP in the same way - static types aren't easy to make work with the freely message passing world of OTP. They are implementing a lot of the same concepts, but that's work that Gleam has to do. (Elixir provides some thin API wrappers over the Erlang OTP APIs, and then also provides some additional capabilities like Tasks).

cies 1y ago

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

Blackarea 1y 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 1y 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 1y 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 1y 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 1y 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 1y 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.