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

Elixir 1.19

elixir-lang.org

Post reply on HN
Print view View original

141–150 of 152 posts

Re: Elixir 1.19

#141

Post by [deleted] »

oxidant wrote: post #114
dnautics wrote: post #51

Earlier quoted context omitted.

> The idea that Phoenix is also mostly macros does not hold in practice no, but the Framework does push you into using them. A good example is the `use MyAppWeb` pattern. That's a macro that nests other macros. the good news is that you can pretty much excise that and everything works fine, and LLMs have no problem even! (i think they slightly prefer it) a few cognitive pain points with phoenix macros: plug: (love it…

What do you mean, "creates a Conn variable out of whole cloth"? Conn is just a pipeline of functions, the initial Conn struct is created at request time and passed through to each function in the pipeline.

[deleted]

Re: Elixir 1.19

#142

Post by throwawaymaths »

Blackarea wrote: post #18

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

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".

Re: Elixir 1.19

#143

Post by dns_snek »

29athrowaway wrote: post #140
dns_snek wrote: post #132

Earlier quoted context omitted.

I think it would be easier for all of us to understand if you elaborated on what you think the issues are. What concrete things are you missing from ExUnit and documentation, what do you wish was different?

You can ask ChatGPT or any major model: from the perspective of an expert technical writer/information architect, how would it evaluate the Elixir documentation, and it will surface key issues.

I don't care what a sycophantic machine "thinks" because I can get any answer I want out of it by subtly changing the phrasing of the question. I thought you had legitimate points to discuss in good faith, not this nonsense.

Re: Elixir 1.19

#144

Post by 29athrowaway »

dns_snek wrote: post #143
29athrowaway wrote: post #140

Earlier quoted context omitted.

You can ask ChatGPT or any major model: from the perspective of an expert technical writer/information architect, how would it evaluate the Elixir documentation, and it will surface key issues.

I don't care what a sycophantic machine "thinks" because I can get any answer I want out of it by subtly changing the phrasing of the question. I thought you had legitimate points to discuss in good faith, not this nonsense.

Take the documentation of GenStage, for example. It is a dry transition between what a stage is into advanced concepts with diagrams are in ASCII. https://hexdocs.pm/gen_stage/GenStage.html

Not only this article dumps significant cognitive load on the reader. It's not well digested and not a soft landing into the subject. Worst of all, many Elixir articles assume familiarity with GenStage.

Compare it to this, which is not the best example but is a much more soft landing. https://doc.akka.io/libraries/akka-core/current/typed/actors...

Re: Elixir 1.19

#145

Post by Hasnep »

throwawaymaths wrote: post #142
Blackarea wrote: post #18

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

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 a…

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.

Re: Elixir 1.19

#146

Post by throwawaymaths »

Hasnep wrote: post #145
throwawaymaths wrote: post #142

Earlier quoted context omitted.

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 a…

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.

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.

Re: Elixir 1.19

#147

Post by h14h »

This might be hot take, but I really wish Elixir had more variety in its ecosystem -- particularly in its client-side ergonomics.

I absolutely love the language, the way it fits into the Erlang runtime, and especially Jose's stewardship. But Phoenix/LV don't jive with my brain nearly as well as Elixir itself does. Additionally, the push towards native development never evolved to a place where it could realistically supplant Expo & RN for me.

This probably sounds insane to anyone who hates how the TS/JS community has a million different frameworks, but I think the upside of all that chaos is that a plethora of new ideas that get explored, and the truly exceptional ideas end up getting adopted anywhere.

My gut feeling is that the Elixir world has a TON of amazing ideas that have yet to be explored.

Re: Elixir 1.19

#148

Post by Hasnep »

throwawaymaths wrote: post #146
Hasnep wrote: post #145

Earlier quoted context omitted.

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.

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.

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 :)

Re: Elixir 1.19

#149

Post by maharajatever »

spooky_deep wrote: post #86
orthoxerox wrote: post #81

Earlier quoted context omitted.

It's not dead dead, but no new projects are choosing it. Those that chose Scala as the better Java can now just use the better Java from the latest JDK.

Scala still offers lots over modern Java. The issue for me is that Scala design lacks focus. They say yes to too many features.

[dead]

Re: Elixir 1.19

#150

Post by throwawaymaths »

Hasnep wrote: post #148
throwawaymaths wrote: post #146

Earlier quoted context omitted.

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.

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 :)

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.

Post reply on HN