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

Elixir 1.2.0 Released

github.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Elixir 1.2.0 Released

#61

Post by josevalim »

gleb wrote: post #58
szx wrote: post #43

I'd be curious to hear some criticism, negative experiences, downsides from people with deeper experience. This thread is 100% positivity and praise, which is highly unusual for HN (New Year's afterglow??) To be clear, my occasional dabbling in Elixir has yet to reveal any major shortcomings so this isn't an elephant in the room kind of situation, just a genuine request from people whose thoughtful opinions I general…

We are rewriting an internal Rails application in Elixir as a test project. I like what I see so far. Elixir/Phoenix promise it to be like Rails but 10x faster with 1000x less memory use and better concurrency. Our preliminary data is that it does deliver that. But there are definitely problems. The only one that really concerns me is Ecto and its integration in Phoenix. It makes simple things hard and hard things im…

I would love to hear more about the Ecto/Phoenix integration and what feels hard and what feels impossible. Feel free to shot me an e-mail or ping me on IRC.

Re: Elixir 1.2.0 Released

#62

Post by lostcolony »

im_down_w_otp wrote: post #56
lostcolony wrote: post #52

Earlier quoted context omitted.

I think a lot of it is Elixir's niche, too. Unlike most of the languages talked about on HN, the BEAM makes no bones about what considerations it's made, and what sorts of problems it is and is not intended for. While there are a few just general warts to be found, they tend to either be obviously surface level things ("I don't like ~this~ bit of syntax"), or so deep you are unlikely to hit them (the issue with large…

You could do a lot of fast number crunching if you wanted to. It just gets tricky to implement without screwing with the primary scheduler pool. I've written many NIFs for Erlang that call out to high-performance C routines when "number crunching" is most important. I've also done it to side-step memory allocator churn for implementing binary protocols that support zero-copy semantics like Capnp by using the NIF as a…

You're not using Erlang/Elixir for number crunching; you're using it for orchestration of your C code.

That's my point; in a niche language, you only try to use it to solve the problems it claims or you have reason to believe it to be good at, thus, its limitations (both declared and any you run into outside of the claims it makes) are dismissed with "you're using the wrong tool", a fact the developer usually realizes themselves, and does not treat as a deficiency of the language.

If you had reason to believe Erlang was good at number crunching, and wrote code to crunch numbers in it, and then found it wasn't, you'd complain about how slow it is. Because you never had that expectation, because Erlang flat out says it's not good at that, you knew to instead write NIFs. The thought "this language should be faster" never entered your mind, because that kind of performance is not the goal of the language. Instead you used it where its reliability and scalability come into play, things it is good at, and offloaded the number crunching to a language better suited for it.

Re: Elixir 1.2.0 Released

#63

Post by im_down_w_otp »

lostcolony wrote: post #62
im_down_w_otp wrote: post #56

Earlier quoted context omitted.

You could do a lot of fast number crunching if you wanted to. It just gets tricky to implement without screwing with the primary scheduler pool. I've written many NIFs for Erlang that call out to high-performance C routines when "number crunching" is most important. I've also done it to side-step memory allocator churn for implementing binary protocols that support zero-copy semantics like Capnp by using the NIF as a…

You're not using Erlang/Elixir for number crunching; you're using it for orchestration of your C code. That's my point; in a niche language, you only try to use it to solve the problems it claims or you have reason to believe it to be good at, thus, its limitations (both declared and any you run into outside of the claims it makes) are dismissed with "you're using the wrong tool", a fact the developer usually realize…

That's a fair point. Though the thought, "this language should be faster" has crossed my mind many times during the pain of all that other mucking about I had to do :-)

I'm timidly hopeful that projects like ErLLVM and BEAMJIT will eventually produce enough improvement to BEAM performance for computational workloads that using FFI escape hatches only becomes necessary in the most extreme fringe of circumstances.

The fact that the NIF interface is so damned straight forward to work with compared to FFI implementations in other systems does ease the pain a bit of having to step out to consume it more often than I might its analogue in other languages.

Re: Elixir 1.2.0 Released

#64

Post by simoncion »

gleb wrote: post #58
szx wrote: post #43

I'd be curious to hear some criticism, negative experiences, downsides from people with deeper experience. This thread is 100% positivity and praise, which is highly unusual for HN (New Year's afterglow??) To be clear, my occasional dabbling in Elixir has yet to reveal any major shortcomings so this isn't an elephant in the room kind of situation, just a genuine request from people whose thoughtful opinions I general…

We are rewriting an internal Rails application in Elixir as a test project. I like what I see so far. Elixir/Phoenix promise it to be like Rails but 10x faster with 1000x less memory use and better concurrency. Our preliminary data is that it does deliver that. But there are definitely problems. The only one that really concerns me is Ecto and its integration in Phoenix. It makes simple things hard and hard things im…

> It's missing a lot of basic scripting language functionality (e.g. wrappers over libc functions).

What libc stuff are you missing? (I'm rather interested in the answer to this question! :) )

It's entirely possible that the functions that you want are available in the Erlang standard library, which can be trivially accessed from Elixir.

Re: Elixir 1.2.0 Released

#65

Post by gleb »

simoncion wrote: post #64
gleb wrote: post #58

Earlier quoted context omitted.

We are rewriting an internal Rails application in Elixir as a test project. I like what I see so far. Elixir/Phoenix promise it to be like Rails but 10x faster with 1000x less memory use and better concurrency. Our preliminary data is that it does deliver that. But there are definitely problems. The only one that really concerns me is Ecto and its integration in Phoenix. It makes simple things hard and hard things im…

> It's missing a lot of basic scripting language functionality (e.g. wrappers over libc functions). What libc stuff are you missing? (I'm rather interested in the answer to this question! :) ) It's entirely possible that the functions that you want are available in the Erlang standard library, which can be trivially accessed from Elixir.

E.g. mktemp and friends. Or more generally, a secure way to work with temporary files.

Subprocess control, e.g. popen seems different/hard. We are using Porcelain though, which is nice. This thread on the list about working with pty's didn't inspire confidence either: http://comments.gmane.org/gmane.comp.lang.elixir.general/457...

Another Unixy thing that's missing in a hard-to-believe sort of way is Unix domain sockets. Makes connecting to Postgres irritating.

Re: Elixir 1.2.0 Released

#66

Post by gleb »

josevalim wrote: post #61
gleb wrote: post #58

Earlier quoted context omitted.

We are rewriting an internal Rails application in Elixir as a test project. I like what I see so far. Elixir/Phoenix promise it to be like Rails but 10x faster with 1000x less memory use and better concurrency. Our preliminary data is that it does deliver that. But there are definitely problems. The only one that really concerns me is Ecto and its integration in Phoenix. It makes simple things hard and hard things im…

I would love to hear more about the Ecto/Phoenix integration and what feels hard and what feels impossible. Feel free to shot me an e-mail or ping me on IRC.

Email WIP.

Re: Elixir 1.2.0 Released

#67

Post by [deleted] »

josevalim wrote: post #61
gleb wrote: post #58

Earlier quoted context omitted.

We are rewriting an internal Rails application in Elixir as a test project. I like what I see so far. Elixir/Phoenix promise it to be like Rails but 10x faster with 1000x less memory use and better concurrency. Our preliminary data is that it does deliver that. But there are definitely problems. The only one that really concerns me is Ecto and its integration in Phoenix. It makes simple things hard and hard things im…

I would love to hear more about the Ecto/Phoenix integration and what feels hard and what feels impossible. Feel free to shot me an e-mail or ping me on IRC.

[deleted]

Re: Elixir 1.2.0 Released

#69

Post by dwoot »

Spiritus wrote: post #23
quaunaut wrote: post #2

How ironic, I was wondering just last night when 1.2 would be released. I'm a newcomer to Elixir, and have really been enjoying it. As a Python->Rubyist, it's been really interesting to finally hit a functional language, and some of Elixir's most basic features just seem crazy in comparison to what I've come from. Some neat examples: * Pattern Matching. In other words- you don't assign things to variables, you match…

Not knowing Elixir at all, what's with all the & operators in your pipe example? Looks very unappealing to me.

We call it the "capture" operator. What it does is it captures the nth parameter of the anonymous function. Like some have already said, the number just signifies which parameter you're making a reference to in the function body. It's terse and comes in handy for ad-hoc stuff. I prefer verbosity and often write Elixir code with the standard syntax and find myself using the capture operator a lot more in the REPL.
Post reply on HN