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

Phoenix 1.0

phoenixframework.org

Post reply on HN
Print view View original

121–130 of 228 posts

Re: Phoenix 1.0

#121

Post by rubiquity »

lpsz wrote: post #105
kamac wrote: post #100

Earlier quoted context omitted.

Out of curiosity, which libs/frameworks are you using in Go? (that are web related)

Hmm, still in the exploratory-hacking phase. Rewrote various parts of what Gorilla provides for learning purposes, plan to switch to Gorilla. Using "lib/pq" (Postgres) for the db. Also: need to cache some computed data in memory, and reload using a REPL or other means, haven't figured out the most "batteries included" way to do so yet. Also: need to figure out the most production-friendly way to redeploy code (sounds…

> Also: need to cache some computed data in memory, and reload using a REPL or other means, haven't figured out the most "batteries included" way to do so yet.

Elixir does nicely here, too. For caching, ets[0] tables are very easy to setup. For reload, you can use IEx to connect to a remote node and do whatever you need to do.

0 - http://www.erlang.org/doc/man/ets.html

Re: Phoenix 1.0

#122

Post by namelezz »

lpsz wrote: 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...

Re: Phoenix 1.0

#123

Post by nailer »

rubiquity wrote: post #120
stock_toaster wrote: post #118

Earlier quoted context omitted.

One thing I really like about Go is that the output is a binary. This significantly reduces some types of infrastructure complexity (deploy, CI, etc). After a long stint as a python dev, I find myself seemingly almost subconsciously avoiding languages that require a ceremonial dance and some type of sacrifice to get all the various bits (dependencies, etc) in just the right place before the app will start up properly…

Elixir is easier to deploy than Python/Ruby. Since Elixir compiles down to bytecode all you need installed on a server is the BEAM (the name of Erlang's virtual machine). It's not as simple as a binary but is still a significant improvement over git-based deployments.

Wouldn't you have to pull the elixir source and then compile the bytecode on the boxes you're deploying onto?

Forgive me if I've missed something. I'm just getting excited about elixir at this stage.

Re: Phoenix 1.0

#124

Post by oomkiller »

agopaul wrote: post #115
ghayes wrote: post #89

Earlier quoted context omitted.

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…

This is very interesting as Phoenix could become the next Rails. I loved Rails and ruby, for the most part, but ruby MRI still lack 'Native Threading', and Jruby isn't viable if you are using external C extensions. To overcome the lack, I've used Resque (or beanstalkd in PHP, which has the exact same problem) as a background job manager, but then I had to write my own layer and rely on the database to handle the 'job…

The best example is probably channels. The framework doesn't really have to provide you anything for you to be able to use concurrency. For a personal example, I was able to use RethinkDB changefeeds easily with channels: https://github.com/bbhoss/elixir_friends/blob/master/web/cha...

I just start another process when you join a channel, and that process sets up the changefeed and pushes changes to the client in the form of HTML, allowing messages to be received and processed by the channel. You can watch the full presentation here: https://www.youtube.com/watch?v=aWaleoYD1Ro Slides: http://www.slideshare.net/bbhoss/otp-phoenix-channels-rethin...

Another example is sending email. In Rails, you need to have something like Sidekiq (or now Activejob) to be able to background the job so it doesn't block the response to the client. In Phoenix, you can simply spawn a process to do the work and move on. Sure, you might want a system like exq to keep track of things a bit better, but ultimately the concurrency primitives provides by Erlang/Elixir allow you to do everything you need.

Re: Phoenix 1.0

#125

Post by oomkiller »

hartator wrote: post #84
oomkiller wrote: post #73

Earlier quoted context omitted.

Can't say much about the details yet, but I work here: http://www.reactionhousing.com/ :)

Maybe a stupid question, but why would you need something like exilir?

I like Elixir because of its ability to do distributed computing, fault tolerance/HA, binary pattern matching, speed, and more. You don't need Elixir, but it makes a lot of stuff much easier to do.

Re: Phoenix 1.0

#126

Post by rodgerd »

wiremine wrote: post #108

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…

At an introductory level, Katie Miller's "Programming in Elixir" from LCA 2014 is a good talk: https://www.youtube.com/watch?v=uWSGBpW3xEQ

Re: Phoenix 1.0

#127

Post by agopaul »

agopaul wrote: post #115
ghayes wrote: post #89

Earlier quoted context omitted.

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…

This is very interesting as Phoenix could become the next Rails. I loved Rails and ruby, for the most part, but ruby MRI still lack 'Native Threading', and Jruby isn't viable if you are using external C extensions. To overcome the lack, I've used Resque (or beanstalkd in PHP, which has the exact same problem) as a background job manager, but then I had to write my own layer and rely on the database to handle the 'job…

@oomkiller: again, so interesting, especially when used in combination with RethinkDB.

I'll have a look at the slides

Re: Phoenix 1.0

#128

Post by rubiquity »

nailer wrote: post #123
rubiquity wrote: post #120

Earlier quoted context omitted.

Elixir is easier to deploy than Python/Ruby. Since Elixir compiles down to bytecode all you need installed on a server is the BEAM (the name of Erlang's virtual machine). It's not as simple as a binary but is still a significant improvement over git-based deployments.

Wouldn't you have to pull the elixir source and then compile the bytecode on the boxes you're deploying onto? Forgive me if I've missed something. I'm just getting excited about elixir at this stage.

There's releases where you can build a tarball[0] or RPM[1] that includes your application byte code plus the BEAM. Here's how you can go about building, testing and deploying a release in the context of Phoenix specifically: http://www.phoenixframework.org/v0.13.1/docs/advanced-deploy...

Optionally, you could cross compile locally or compile on a build server and have the other nodes pull from there, same as you would do in Go.

0 - https://github.com/bitwalker/exrm

1 - https://github.com/smpallen99/exrm-rpm

Re: Phoenix 1.0

#129

Post by josevalim »

namelezz wrote: post #122
lpsz wrote: 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...

The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development?

For example, Elixir is a more "strict" dynamic language than your usual Python/Ruby/Javascript. Data is immutable. There is no monkey patching. Most state changes happen explicitly via process communication. The macro system is compile-time which means nothing will pull the carpet under your feet at runtime.

Also long-term productivity is about actually maintaining your system in production. And Elixir leverages 3 decades of experience on that, using a runtime designed to build systems that self-heal and are fault-tolerant (I slightly explore this here: http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...).

I don't want to give a yes or a no answer, I would just like to point out the line is much blurrier than that. It doesn't matter which type system you use, your code is going to have bugs or unexpected situations will arise, specially when we are talking about network. So knowing that your system system can heal itself is quite comforting.

Those are two complementary aspects. It is one of the reasons I would love to see a statically typed language succeed in the Erlang VM.

Post reply on HN