Live data from Hacker News

Phoenix 1.0

phoenixframework.org

111–120 of 228 posts

Re: Phoenix 1.0

#111
post #107
post #105

Earlier quoted context omitted.

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…

Relating to redeploying code, did you give https://github.com/codegangsta/gin a look? Also, any particular reason to not use a web framework such as gin-gonic for routing and templating? It simplifies some things down for me.

Re: gin, thanks for the tip. I feel like this one makes more sense in development than in production, would like to avoid side effects (first HTTP request restarts the server), also an extra proxy layer.

Re: web framework. Absolutely, no intention to reinvent the wheel. Just informative to rewrite various pieces in the initial stages to get a better grasp on the language/patterns.

Re: Phoenix 1.0

#112

Earlier quoted context omitted.

You can do reasonable metaprogramming in Erlang with the syntax_tools and stdlib interfaces. Most famously was bringing back parameterized modules via a parser transformation for tools like BossDB to support ActiveRecord-like ORM patterns. I've looked at OTP the Elixir way and I do not see any real boilerplate reduction. The application-project dichotomy and the opinionated integration with a tool like Mix is also po…

> 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 that.

Take a look at Elixir's agents or tasks and explain how it doesn't lead to more readable and cleaner code than the GenServer equivalent in Erlang for the cases they fit.

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. I should really switch an entire language because of default libraries?

This sentence is specially ironic given that Erlang inherits from Prolog, which is quite different semantically from Erlang

Only traces. The Prolog influence of Erlang is severely overrated by a lot of people these days.

Also Erlang is pretty much a very dynamic language.

It ain't no Smalltalk. The runtime is very dynamic, and the typing is loose, but the Erlang language itself not so much, which I think is a strength.

I am a Haskell developer, I hate Ruby syntax and I programmed Erlang for a year.

Good for you, chap.

Re: Phoenix 1.0

#113
post #111
post #107

Earlier quoted context omitted.

Relating to redeploying code, did you give https://github.com/codegangsta/gin a look? Also, any particular reason to not use a web framework such as gin-gonic for routing and templating? It simplifies some things down for me.

Re: gin, thanks for the tip. I feel like this one makes more sense in development than in production, would like to avoid side effects (first HTTP request restarts the server), also an extra proxy layer. Re: web framework. Absolutely, no intention to reinvent the wheel. Just informative to rewrite various pieces in the initial stages to get a better grasp on the language/patterns.

About gin, you're right, I think. But what else to use in case the app crashes? A simple shell script to restart the executable whenever it crashes (even though it shouldn't)? :) And what about hot code reloads? You'd have to stop the app for a second there, and replace the executable yourself. You'd also probably interrupt whatever the app was doing at the time, which could turn out pretty bad.

Re: Phoenix 1.0

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

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' result.

Which parts of the framework leverage the concurrency model, other than the routing/request handling part?

Re: Phoenix 1.0

#116
post #113
post #111

Earlier quoted context omitted.

Re: gin, thanks for the tip. I feel like this one makes more sense in development than in production, would like to avoid side effects (first HTTP request restarts the server), also an extra proxy layer. Re: web framework. Absolutely, no intention to reinvent the wheel. Just informative to rewrite various pieces in the initial stages to get a better grasp on the language/patterns.

About gin, you're right, I think. But what else to use in case the app crashes? A simple shell script to restart the executable whenever it crashes (even though it shouldn't)? :) And what about hot code reloads? You'd have to stop the app for a second there, and replace the executable yourself. You'd also probably interrupt whatever the app was doing at the time, which could turn out pretty bad.

I use upstart to respawn if crashes, but there's definitely more than one way to solve this one :) Hot code reloads is the more interesting issue.

Re: Phoenix 1.0

#117
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-...

Thanks, I actually read!

"The Go devs have since stated that they were surprised to see that a lot of Go converts were from dynamic languages like Python and not C or C++. Go still makes sense for a lot of apps ... somewhere, however, that has been extrapolated to the idea that Go is a good language for writing web apps."

I think this is the crux of the question. And heck, it's very easy to spin up a web server in Go, and so many intro examples focus on that.

Re: Phoenix 1.0

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

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.

Re: Phoenix 1.0

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

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…

Yes, and the standard Go workspace layout (and therefore not even needing a makefile) is great.

Re: Phoenix 1.0

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

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.
Post reply on HN