Live data from Hacker News

Phoenix 1.0

phoenixframework.org

191–200 of 228 posts

Re: Phoenix 1.0

#191
Man I went to an Erlang meeting a year ago and all the people there were talking about how to get Erlang to be popular.

I basically said look at Ruby, it shot up because of RoR. All erlang needs is a good hype web framework.

Everybody in that room was like nope, the people can't see the power of Erlang and Erlang only solve a niche problem or that web framework isn't the answer.

Uh huh. Phoenix is evidence that programming language needs a good framework and a big user base that are hype about it. Sadly I don't see Erlang going to get momentum as Elixir and I think it's a good thing. Erlang can do it thing and Elixir can bring in more people on to the Erlang VM (BEAM).

Re: Phoenix 1.0

#192

Earlier quoted context omitted.

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

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. I can't comment on excellent tooling. Language-specific package managers never tend to be excellent, which is why I appreciate the limited scope of a tool like rebar. Again, you are overvaluing a language based on the libraries it expor…

Except I am not. What would be Erlang really without OTP? Would you really want to implement all the building blocks in every new project? You are dismissing the importance behind stdlib while defending a language that is known specially because of its standard library (Erlang/OTP).

Also rebar3 is pretty much the same in scope as Mix (elixir tool). Which proves the point you are criticizing Elixir while using the same criteria to praise Erlang.

I am not saying Elixir is better or worse, just pointing you are extremely biased in your comments.

Re: Phoenix 1.0

#194

Earlier quoted context omitted.

> 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? They're both statically typed, but the type systems obviously aren't equal. I would argue that stricter types are in fact one of the main things that helps me be more productive in languages with MLish type systems…

They're both statically typed, but the type systems obviously aren't equal. That was his point.

I suppose the main difference is the presence of algebraic data types. But does that even make sense without static typing?

Re: Phoenix 1.0

#195
Wow,excited to see this. I'm following phoenix since its 0.10 days and i'm proud to say it has come a long way. Using phoenix source for tips and guidance while im developing a web framework for Erlang (Entirely for learning purposes). Amazing work team Phoenix. Hats off to you!

Re: Phoenix 1.0

#196
post #168

Way to go to ignore most basic web standards, too (JS disabled): http://i.imgur.com/HE3uH4Y.png Please don't participate in the "modern web", thanks.

To be clear to anyone reading this who didn't read the rest of the thread: the docs are hosted on readme.io (YC) and not with a Phoenix build. Readme.io have stated they are working on a better nojs solution.

Re: Phoenix 1.0

#197

Earlier quoted context omitted.

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

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.

Re: Phoenix 1.0

#199

Earlier quoted context omitted.

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 str…

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

A type problem is any problem that types can solve for you. People who are exposed to very limited type systems consider the range of type problems to be limited. Still it is true that most of these problems are solved quickly and caught with unit tests - no one thinks that simple type problems are the source of your production bugs. A good type system is mostly a productivity play for me; I develop a little faster and I refactor MUCH more quickly and with less effort.

Re: Phoenix 1.0

#200

Earlier quoted context omitted.

But you woudn't need gems to for recovery emails right?

The Devise gem does that for free. I remember me coding it in my first Rails application so many years ago and I'm not keen to go back to it: it feels like wasted time. Phoenix didn't have it one year ago and it's sad to learn that it doesn't have it yet. Somebody will write it sooner or later because it's almost core functionality of a registration and authentication system.

Its actually pretty simple to implement on your own. I am not big of device. I feel it does too much magic. It should have been just a api layer and not touching views.
Post reply on HN