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

Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

elixir-lang.org

Post reply on HN
Print view View original

121–130 of 170 posts

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#121

Post by mtndew4brkfst »

sergiotapia wrote: post #51

Can't say enough good things about Elixir and Phoenix. Now with types coming, it'll get even better. By the way, you hear a lot about the BEAM and it's power - but in my experience you can go a LONG LONG LONG way before you ever have to even think about that part of your stack. Phoenix does such a tremendous job abstracting that for you. You just get the gainz with no effort. Other parts of the stack also just abstra…

I fully agree with you were it not for LiveView, which combined with the marketing obsession around LV, means people who could have glossed over OTP for a while longer are now confronted with it much earlier in their journey, possibly on their first controller route.

Writing robust LiveView flows, and testing them well, is exactly as intellectually complex as writing stateful genservers with multiple non-linear flows and various call/cast entry points. LVs use different jargon and have small convenience layers like async-assigns, but mechanically genservers are literally what they are. I'd say that's crucial to understand well if you want to use them effectively.

Love Oban and miss it deeply in other ecosystems.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#122

Post by skrebbel »

mtndew4brkfst wrote: post #29
neillyons wrote: post #15

Nice feature in this release is the addition of `get_in/1` which works with structs. eg. `get_in(struct.foo.bar)` If `foo` returns `nil`, accessing `bar` won't raise.

It was still possible to do this in prior versions of Elixir, just syntactically noisy. Any layer which isn't a vanilla map needs Access.key, as in: get_in(struct, [Access.key(:foo), :bar])

But that’s way less clear than just

    if struct.foo do struct.foo.bar else nil end

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#123

Post by impulser_ »

julienmarie wrote: post #75

The last few years the Elixir ecosystem has started to become the simplest solution to so many use cases: - Web development with Phoenix and Liveview is immensely enjoyable and fast - AI with NX, Axon, Bumblebee - Audio and Video streaming and manipulation with Membrane - CQRS and Event Sourcing with Commanded - Embedded with Nerves to make your own devices - Mobile apps with Liveview Native ( in development ) - Queu…

When you use Elixir you have to go into it knowing you might have to end up maintaining any library you are using because the vast majority of Elixir libraries are abandoned.

You have to search through libraries to find out which one is being maintained.

For example if you want to use an OpenAI API client, you wouldn't want to use the most starred one because that hasn't been maintained in 7 months.

If you just use Python you get to use the one maintained by OpenAI. Using a language like Python, JS, Go ect. you almost never run into this problem because libraries are usually maintained and aren't abandoned and if they are there are usually enough users that a fork appears.

So yeah Elixir has great uses, but is it worth the possible future headaches of having to maintain a bunch of libraries to get your app going? Instead of using Go, Python, JS ect where you can rely on a massive community

Very very few companies build and maintain SDKs for Elixir.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#124

Post by mtndew4brkfst »

skrebbel wrote: post #122
mtndew4brkfst wrote: post #29

Earlier quoted context omitted.

It was still possible to do this in prior versions of Elixir, just syntactically noisy. Any layer which isn't a vanilla map needs Access.key, as in: get_in(struct, [Access.key(:foo), :bar])

But that’s way less clear than just if struct.foo do struct.foo.bar else nil end

Sure, this snippet is a trivial example and doesn't sufficiently motivate get_in and family, which can be much more powerful when needs aren't so simple.

It's also very hard to be as concise with more vanilla syntax when competing with put_in/update_in instead. The pattern and ability to generalize it is valuable IME.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#125

Post by mahguy »

julienmarie wrote: post #75

The last few years the Elixir ecosystem has started to become the simplest solution to so many use cases: - Web development with Phoenix and Liveview is immensely enjoyable and fast - AI with NX, Axon, Bumblebee - Audio and Video streaming and manipulation with Membrane - CQRS and Event Sourcing with Commanded - Embedded with Nerves to make your own devices - Mobile apps with Liveview Native ( in development ) - Queu…

[dead]

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#126

Post by cess11 »

Thaxll wrote: post #84
dankai wrote: post #65

Earlier quoted context omitted.

A news aggregator (and premium news chatbot) that indexes and analyses around ~150.000 new articles a day ( http://im.fo ) I'm absolutely certain the real time processing would be unfeasible in any other technology in terms of complexity and the minimal compute resources it's running on. Modules like broadway, ash, oban, phoenix liveview ... make it not just a pleasure to work with but insanely performant. With over…

You know that Elixir is on the low end of performance right, so you take Go/Java/C# that are close to 10x faster.

If you need per-core number crunching performance you'd reach for Nx, similar to how you would do the crunching in Python. With OTP it's then (almost) trivially concurrent.

Compared to squeezing performance out of multiple cores with the JVM it's absurdly convenient and consumes way less RAM. I have two reasons for still working with the JVM, multiplatform desktop GUI and high quality PDF libraries that support rather low-level aspects of the standard that I need. It's kind of obvious why these things aren't readily available on the BEAM, though.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#127

Post by cess11 »

theflyinghorse wrote: post #82
Tao3300 wrote: post #74

Earlier quoted context omitted.

Last time I looked at Elixir, it seemed like the consensus was "you're going to need to do Erlang too". Is that still the case, or is dipping down into Erlang no longer required?

As elixir noob I find I reach into erlang often, mostly for things like sets, queues. Do people often end up writing erlang alongside elixir code in the same project?

I'd say it's uncommon but you'll often use Elixir wrappers around OTP stuff or Erlang libraries. Sometimes there isn't a wrapper for the library you want so you'd just call into the Erlang library directly, which is much easier and "noob"-friendly than FFI:s usually are.

For sets it's usually recommended to use Elixir MapSet. There is a Queue-wrapper around the FIFO-queue in OTP as well. For fun and learning you can also implement your own queues, or things like process pooling around the tooling already available.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#128

Post by cess11 »

vohk wrote: post #101

Any recommendations for an entry point into Elixir? I've been teaching myself Rust through resources like Rustlings and 100-exercises-to-learn-rust, and I've found that approach to be pleasantly accessible. I've yet to find something similar for Elixir, whether interactive or just well laid-out.

Boot up a Livebook and step through some of the basics on the Elixir homepage. Someone else recommended Elixir in Action, which is a very good book once you have some grasp on the fundamentals.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#129

Post by externedguy »

impulser_ wrote: post #123
julienmarie wrote: post #75

The last few years the Elixir ecosystem has started to become the simplest solution to so many use cases: - Web development with Phoenix and Liveview is immensely enjoyable and fast - AI with NX, Axon, Bumblebee - Audio and Video streaming and manipulation with Membrane - CQRS and Event Sourcing with Commanded - Embedded with Nerves to make your own devices - Mobile apps with Liveview Native ( in development ) - Queu…

When you use Elixir you have to go into it knowing you might have to end up maintaining any library you are using because the vast majority of Elixir libraries are abandoned. You have to search through libraries to find out which one is being maintained. For example if you want to use an OpenAI API client, you wouldn't want to use the most starred one because that hasn't been maintained in 7 months. If you just use P…

> Very very few companies build and maintain SDKs for Elixir.

This is true with any tech until it gets traction. React/Next is backed by a big company, but Vue/Nuxt still managed to grab its piece of the pie.

In order to get traction Erlang / Elixir needs enthusiasts who are ok with risking and introducing it to their company or product, at least partially.

No offense, but instead of condemning the Elixir ecosystem, why not embrace it in your company or product, as many have done (including me)? I think most devs should be OK with taking a tolerable risk if they see opportunity to increase productivity by N times

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#130

Post by myaccountonhn »

birdfood wrote: post #77
elbasti wrote: post #56

Earlier quoted context omitted.

I love elixir. I use it for basically everything. And LiveBook has become my go-to place to start building toy software. I just can't do liveview. I have a very hard time grokking it, and it has a lot of footguns. (ex: if you need to remember to perform auth checks both doing a `pipe_through` in a router and using the `on_mount` callback in a LiveView, see [0].) In fact, the fact that the above sentence has zero mean…

I've been having a similar experience trying to build an app with liveview. I've been simultaneously building the same app with Phoenix + LiveView and Dream (OCaml) + HTMX. With the OCaml stack I'm finding it really easy to follow the data flow through the whole app thanks to the compiler. With the Phoenix app I'm struggling to internalise how all the code fits together and having to navigate the code base off search…

I echo this. It’s always the struggle of DIY + understanding what’s going on versus taking the magic off the shelf solution where it works until it doesn’t.
Post reply on HN