Live data from Hacker News

Phoenix 1.0

phoenixframework.org

131–140 of 228 posts

Re: Phoenix 1.0

#131
post #89

Earlier quoted context omitted.

Hypothetically speaking, why would you choose Phoenix over Rails for a new app?

Phoenix shares many features with Ruby on Rails, e.g. a strong MVC model, an integrated ORM, a routing system, etc. What Phoenix on Elixir excels at is concurrency and distributed computing. For applications, this means you can have many active web sockets, for instance, where Rails applications tend to break down when you have too many active connections. Phoenix uses erlang processes for these tasks, which are ligh…

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; just use processes.

Re: Phoenix 1.0

#132
post #81

Earlier quoted context omitted.

I haven't done much either with Elixir or Ruby (I do more Python and Erlang). But one thing I noticed is Valim (and others on the team) created a really approachable langauge and framework. Their emphasis on new comers, documentation, friendliness of community is outstanding. Also Elixir will bring more people to the BEAM VM and take advantage of it, as I think it is a gem of engineering.

It's great having new people, but hopefully we'll avoid the clusterfuck of gems and node modules that are the hallmark of the perpetually-immature web development community.

I know you're being downvoted but I 100% agree with you. I don't want 100,000 Hex packages. I want a few thousand packages that solve problems really well and people rally around and collaborate on them. NPM and RubyGems are casualties of people seeking open source fame and I hope we can avoid that in Elixir.

Re: Phoenix 1.0

#133
post #88

Earlier quoted context omitted.

Better for building out services. Parallel processing. The supervised process abstractions are incredibly powerful. If you're building another Twitter I would still use Rails. You'll be much more productive. On the other hand, if you need to run parallel tasks or have mission-critical (aka can't go down for anything) work to be done I think you'll find Elixir the perfect combination of Ruby's syntax and Erlang's powe…

Nah, if you really are trying to build the next Twitter Rails is a poor choice for architectural and scaling reasons. No need to repeat Twitter's own mistakes. On the other hand, if you are just building another web app, Rails is the better choice...

I mean, if you're building an app for Twitter scale on day one you're already doing something wrong. But yeah.

Re: Phoenix 1.0

#134

Earlier quoted context omitted.

It's great having new people, but hopefully we'll avoid the clusterfuck of gems and node modules that are the hallmark of the perpetually-immature web development community.

I know you're being downvoted but I 100% agree with you. I don't want 100,000 Hex packages. I want a few thousand packages that solve problems really well and people rally around and collaborate on them. NPM and RubyGems are casualties of people seeking open source fame and I hope we can avoid that in Elixir.

Eh, worst case, we can make another hex that enforces good test coverage and documentation. :)

Re: Phoenix 1.0

#135
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…

I don't know enough about the internals of the languages to speak on that, but here's what has influenced my decision on choosing Elixir: Community: smart people (who I respect) in the Ruby community are getting really excited about (and choosing) Elixir. People like José Valim, Dave Thomas, Bruce Tate, Chris McCord, etc. BEAM and OTP: The Erlang VM and OTP have been battle-tested at Ericsson. It's known for having 9…

One thing that attracts me to Elixir is what it doesn't have to do. Go had to start from 0, Clojure had to build FP on top of Java. If they work at all, it's a success.

By contrast, if Elixir just works, it's useless. Its functionality comes almost entirely from Erlang. Therefore its whole reason to exist is to make using that power more pleasant.

That's why, for example, Jose Valim has said "if you see a bad error message in Elixir, which makes you confused and does not help you solve the problem, pls open a bug report." https://twitter.com/josevalim/status/621933537009246208

Re: Phoenix 1.0

#137

Earlier quoted context omitted.

> You can do reasonable metaprogramming in Erlang with the syntax_tools and stdlib interfaces. You can also do concurrency in Ruby. It is not the same as doing concurrency in Erlang though. The same way doing metaprogramming with syntax tools, parse transforms and what not is nowhere close to a macro system. > I've looked at OTP the Elixir way and I do not see any real boilerplate reduction. So please look again? Tak…

The same way doing metaprogramming with syntax tools, parse transforms and what not is nowhere close to a macro system. I'd wager that's because no one has written tooling to make it compelling to the common programmer. Same with release management for a long time, and hot code reloading. I'd understand if you said that basic substitution macros are nowhere close to actual AST macros, but Erlang has far more than tha…

> I'd understand if you said that basic substitution macros are nowhere close to actual AST macros, but Erlang has far more than that.

Fair point.

> Those are sugar. It's not like you can't define your own behaviors in Erlang. People do it all the time, there's so many good libraries that go beyond stock OTP.

There is a very strong point in providing those as default. If Erlang didn't ship with a gen_server, we would see hundreds of different gen_server implementations and no real consensus. By providing one, all Elixir developers are familiar with it.

In a way, you could define everything Elixir provides as a sugar, after all, it runs in the same VM. Sure, an Erlang library could provide all unicode manipulation functions... but having it all sorted out for me is a great deal. The same way Erlang solves many other things which makes it attractive to many.

That leads me to...

> I should really switch an entire language because of default libraries?

No. But if it provides a really good standard library altogether (unicode, structs, enumerable, etc) with an excellent tooling and powerful abstractions (like protocols), then surely yes.

Re: Phoenix 1.0

#138
reading the comments it's pretty clear that phoenix + elixir - it the best thing since sliced bread. Usually it takes years and couple of versions - to make it tick. But here - boom - 1.0 - everything works great - pretty impresive

Re: Phoenix 1.0

#139
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…

You are probably more productive in Elixir at the early stage of development. However, I personally think Go would be better for long-term development because it is statically typed. You can read more about pros and cons of statically and dynamically type languages [1] [1] http://programmers.stackexchange.com/questions/122205/what-i...

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 taken care of at compile time.

Now what types of errors in Go really hurt you? Race conditions at runtime. I have to be way more careful about that to where it was costing me a lot of time in very concurrent programs. Eventually you develop a paranoia. Go has better tooling to help with this now, but concurrency and a language that prefers pointers just doesn't mix well. In Elixir I don't worry about this because everything is immutable. Now that GOMAXPROCS defaults to NumCPU I think a lot of programs that looked race condition-free probably aren't.

As far as runtime goes, Elixir and Go are at the same mercy but Elixir has much better debubbing capabilities than Go thanks to Erlang.

If you want something that gets you closer to static types and you have the discipline to keep up with running it and maintaining your type annotations, there's always dialyzer.[0].

Post reply on HN