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

151–160 of 228 posts

Re: Phoenix 1.0

#151

Post by tednaleid »

shaunxcode wrote: post #149

What is the "tooling" ( https://www.filepicker.io/api/file/exQlE8JZQ2O2DaLm6cEA ) specifically called? (edit: it is ":observer.start()" from inside iex (elixir repl) http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-... )

That's the Erlang "observer". You can launch it from an iex (elixir) console as simply as: `:observer.start` and see your currently running process. It's super powerful for seeing the state and organization of your current application (though a little ugly). It can also be used to monitor remote nodes easily, kill processes, view state, see application load, etc.

Re: Phoenix 1.0

#152

Post by niklasni1 »

davelnewton wrote: post #142
namelezz wrote: post #122

Earlier quoted context omitted.

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 heard this argument before. For a long time, actually. But the kinds of errors I have are only rarely related to type issues, and those are almost always caught very early. YMMV, that's just been my experience.

Having worked with Scala a lot recently, I've found that the ability to turn logic issues into type issues is an incredible gain for my productivity. OCaml programmer Yaron Minsky summed it up nicely with the advice that you should "make illegal states unrepresentable". He gives a good example of modelling a network connection in [0].

Another example is instead of shuffling a bunch of bare UUID objects around (or strings, for that matter) in a system where lots of different things have a UUID, I can make a simple reference type for the IDs of different entities. This way, calling a function that takes the UUID of one type of entity with that of another can be a type error that's caught by the compiler instead of a logic error that's caught by a unit test. This is cumbersome at best to do in Java or C, and obviously impossible in Python or Ruby, but in ML-inspired languages it's simply the most natural way to work.

[0] https://vimeo.com/14313378

Re: Phoenix 1.0

#153

Post by namelezz »

josevalim wrote: post #129
namelezz wrote: post #122

Earlier quoted context omitted.

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…

Thank you for sharing. Hopefully, learning Elixir will be a great experience for me.

Re: Phoenix 1.0

#154

Post by [deleted] »

davelnewton wrote: post #142
namelezz wrote: post #122

Earlier quoted context omitted.

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 heard this argument before. For a long time, actually. But the kinds of errors I have are only rarely related to type issues, and those are almost always caught very early. YMMV, that's just been my experience.

[deleted]

Re: Phoenix 1.0

#155

Post by gkoberger »

happyfriend wrote: post #9

Does phoenix require javascript, or just this announcement page? I see a big block of text mixed with json... Not so good for noscript users and search engines that don't load JS.

Our (ReadMe.io) fault! We're releasing a JS-free version in the very near future :)

Re: Phoenix 1.0

#156

Post by strmpnk »

davelnewton wrote: post #141
nathan_long wrote: post #135

Earlier quoted context omitted.

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…

Clojure built FP on the JVM, not Java. Elixir introduces language features onto BEAM. I guess I don't see the comparison making sense here. Elixir's functionality comes from BEAM and the language, not Erlang.

Elixir actually compiles to the Erlang AST and thus is leveraging Erlang much more than it might seem.

Re: Phoenix 1.0

#158

Post by nfm »

nathan_long wrote: post #131
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…

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 :)

Re: Phoenix 1.0

#159

Post by elithrar »

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…

> Hmm, still in the exploratory-hacking phase. Rewrote various parts of what Gorilla provides for learning purposes, plan to switch to Gorilla.

Good pick. The gorilla toolkit is definitely flexible. I typically use a mix of gorilla (context, csrf, schema) and Goji (routing, middleware chaining).

My 'hard and fast rule' is that everything needs to implement the http.Handler interface if I'm going to use it, so I don't get abandoned with a bunch of custom libraries that I need to refactor away from.

> Also: need to figure out the most production-friendly way to redeploy code (sounds like Erlang/Elixir can do really well in this regard.)

Most typically use the system's init daemon, and/or Supervisor/Circus/monit. I'm partial to Supervisor on that front for the cross-platform compat.

Re: Phoenix 1.0

#160

Post by ChuckMcM »

davelnewton wrote: post #146
ChuckMcM wrote: post #80

Earlier quoted context omitted.

True, my thinking was one level up the stack, Phoenix is (according to Chris' talk) a framework for building applications. And it does this using Elixir running on Erlang. Is Elixir special? Sure it is, but "framework for building apps using language X which is run by virtual machine Y" is the basic pattern for JavaScript, Clojure, Scala, Java, and others. There are a lot of them, they have varying levels of integrat…

Describe a "new problem". I only rarely encounter truly unique problems. One thing it does do is allow scalability in a pretty straight-forward, integrated way.

I like the scaling aspect of it very much.

There are lots of "new" problems with respect to changing conditions in our day to day lives. Here are a few

- Identity management across Internet and non-Internet properties

- Configuration, control, auditing, and monitoring of billions of Beacon level devices

- Zero knowledge proofs as a technique for anonymous and no repudiated purchases online

- "home" level cloud services for local and on the road implementation of always available services (mail, journaling, calendaring, Etc.)

- Reliable third party payment systems (somewhat of an old system but one that benefits from revisiting with current technology from time to time)

- Navigation and cartography tools for people in disconnected regions of the planet.

- Civil process augmentation with automation and authentication.

- Connectivity as a tax payer civic utility, without an editorial bias.

-Dynamic skills assessment for students in the presence of confounding factors (mostly remote access)

- Low friction capital markets for charitable giving (think Watsi but for everything, and with better controls than 'GoFundMe')

- Providing civic services for indigenous homeless populations.

I could go on, there are lots and lots of problems. But to be clear it isn't a criticism of Phoenix that they are not solving a new problem, the feedback was that there are lots of solutions to the general form of problem they are solving and, as feedback on this announcement, I was trying to learn from their materials how they were different (and presumptively better) than those other solutions. I'm still looking for that summary somewhere.

Post reply on HN