Live data from Hacker News

Phoenix 1.0

phoenixframework.org

201–210 of 228 posts

Re: Phoenix 1.0

#201

Earlier quoted context omitted.

I see; I thought it compiled to BEAM code directly. I'd wonder then if there's anything representable in the Erlang AST that can't be represented by Erlang itself; it doesn't look like it so far.

There's not - see docs for parse transforms. Erlang is homoiconic in the sense that it's parse tree is its own valid data-structure literal. This is also true for Elixir. The difference is the `quote` and `unquote` macros and a simpler parse tree format in Elixir, which makes meta-programming much easier than in Erlang from what I understand.

I have rarely read things that were that much wrong. Just because the code can be represented as a data structure, or just because the compiler is written in its own language, that doesn't make a language homoiconic.

Re: Phoenix 1.0

#202

Earlier quoted context omitted.

I wouldn't classify those as "type problems" but rather "using types to solve problems". I have no issue with the claim that great type systems make some... ahem... types of problems go away, although it's often trading one type of complexity for another. My issue is with the claim that "long term development is intrinsically better with static typing".

The type system, at least more powerful ones, encode a lot of intention and more importantly, enforce it. It might add some additional complexity in the first writing of the code, but in return you eliminate whole classes of problems forever. It's not just the initial writing that benefits (at some cost, admittedly), but all future changes won't have those problems either. In the case the types themselves need to cha…

If you're talking about a good type system, sure. The type system in Go is frankly terrible at describing the kinds of invariants and reuse we care about.

I'd dare say that diaylizer (Elixir's optional but easy to use type system) would lead to more maintainable code than Go's forced type system in the long run.

Re: Phoenix 1.0

#203
post #77

After spending nearly 7 years in the Ruby and Rails ecosystem, I changed jobs and have been working in with Elixir and Phoenix for nearly 3 months. I have been very satisfied with the process. The community is amazing, the tooling is unbeatable, and the quality and availability of open source libraries is great, especially for such a young project. The future looks very bright for Elixir and Phoenix!

Agreed. One of the many things that makes Phoenix/Elixir great for us rails/ruby refugees is that it's built by other rails/ruby refugees. In many ways, we have all the good things that our old masters DHH trailblazed with rails, but at the same time, very little of the mess that also came with the trail-blazing. That being said, I do miss active_support though; Elixir's utility libraries (fox, pipe, croma, etc.) doe…

The flip side is that everyone is trying to write Ruby packages and projects in Elixir rather than thinking out of the box as to what is best for this new programming paradigm.

Re: Phoenix 1.0

#204
post #71

Earlier quoted context omitted.

Erlang processes have state and you interact with them by sending them messages. You can do OO if you want :P

Oddly enough you can do OO with Erlang/Elixir in a more pure/better (to me) way than you can with more traditional OO languages.

That's because the core of OO (message passing to opaque things) is really all you can do if you have a PID. In other more-traditional object-oriented languages, they usually have defaults that let you do more than just send messages - such as mutate the internal state directly in ways that the object cannot detect.

Re: Phoenix 1.0

#205

If you're new to Elixir, I highly recommend Dave Thomas' book "Programming Elixir" https://pragprog.com/book/elixir/programming-elixir From the website: "You want to explore functional programming, but are put off by the academic feel (tell me about monads just one more time). You know you need concurrent applications, but also know these are almost impossible to get right. Meet Elixir, a functional, concurrent langu…

Dave's book gives a great overview of Elixir.

If you want a deeper look at Elixir - I'd recommend Elixir in Action by Saša Jurić (Manning publications).

Ben Tan Wei Hao's book is also promising (still in early release) - The Little Elixir & OTP Guidebook also Manning.

Re: Phoenix 1.0

#206
post #95

If you were choosing today, would you recommend choosing Elixir over Go for web/back-end development? Would you say Go is more suited for high-performance command-line tools, and Elixir for long-term running stuff? I'm an indie developer building such a back-end (social networking/chat space), have full choice of language. Started using Go earlier this year and mostly happy with it. Should I switch to Elixir in my ne…

No, I won't! I would advice you to learn them both instead, they are on such opposite sides, than knowing both will expand your knowledge in a very fulfilling way.

Nice insight. Learning more languages, especially those that seem to be different, could widen one's perspectives, and able to avoid the issue of learning only hammer and treat all problems as nails.

Re: Phoenix 1.0

#207

Earlier quoted context omitted.

I've used both Go and Elixir so here's my thoughts: Elixir/Erlang aren't your typical dynamic language. Elixir is compiled and has pattern matching. I catch a ton of bugs at compile time in Elixir that I would never catch in Ruby/Python/JS until runtime. Examples of these are misspelled variables/bindings/function names and pattern match that will never actually match. Those are really, really common time wasters all…

You can handle misspelled variables/bindings/function names in Ruby/Python/JS by linting. That's a class of errors that's easy to avoid anywhere with a good text editor.

Due to the extremely dynamic nature of Ruby, I'm not aware of any linter that can catch misspellings when interacting with class or instance variables, dynamically-defined methods, etc.

It's an entirely different level of statically-verifiable correctness.

Re: Phoenix 1.0

#208
post #158

Earlier quoted context omitted.

Another example: I work on a Rails app where the user submits a request to us, and we have to talk to an API to respond. We can't afford to leave the connection open with the user, so we make them poll for results. My understanding is that the cheap processes of Elixir would mean we could just keep a connection open to that user if we wanted to. Similarly, no need for a background processing framework like ActiveJob;…

What webserver are you using? Running puma in threaded mode, even on MRI, should allow your external API calls to run in parallel - this might simplify things a bit :)

Maybe so, but the fact that Rails includes Active Job shows that this is a common problem.

Re: Phoenix 1.0

#209
post #95

If you were choosing today, would you recommend choosing Elixir over Go for web/back-end development? Would you say Go is more suited for high-performance command-line tools, and Elixir for long-term running stuff? I'm an indie developer building such a back-end (social networking/chat space), have full choice of language. Started using Go earlier this year and mostly happy with it. Should I switch to Elixir in my ne…

Elixir, in my experience, is a much more productive and powerful language. If you are a one-man-show I'd pick Elixir any day. Here I am pimping my own stuff but I wrote a related article on this: http://lebo.io/2015/06/22/the-unix-philosophy-and-elixir-as-...

That was a great read, thanks for sharing!

Re: Phoenix 1.0

#210
post #92
post #61

Slightly off-topic, but can someone familiar with both Elixir and Erlang explain what Elixir provides in comparison to Erlang. I'm looking into using Erlang for a new project that requires extensive scaling and concurrency and am coming from a functional background so may be more comfortable with the traditional Erlang syntax. However it seems that perhaps more development and activity is happening on the Elixir side…

Thanks all for your responses, really helpful!

Don't forget LFE (Lisp Flavored Erlang), if you prefer a Lisp syntax to a Ruby syntax that runs on the BEAM, as I do, although Elixir has great momentum right now.
Post reply on HN