Live data from Hacker News

Phoenix 1.0

phoenixframework.org

141–150 of 228 posts

Re: Phoenix 1.0

#141

Earlier quoted context omitted.

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…

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.

Re: Phoenix 1.0

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

Re: Phoenix 1.0

#143

Does Elixir have any kind of signal processing capabilities ala numpy/scipy for the Python ecosystem? I'm doing some stuff right now using a django/nodejs hybrid system (glued together manually) and I'd love to be able to do everything in one language. But the DSP support (seemingly) isn't there in the javascript ecosystem yet. I'd really love something built on erlang because of all the theoretical problems that jus…

There's very little in terms of analytics, statistics, machine learning libraries etc. There also isn't a common dataframe like structure.

Not what I wanted to hear, but thanks for the reply.

Re: Phoenix 1.0

#145

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…

> 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 compared to C which lacks e.g. generics and proper sum types.

That said, I find Elixir very interesting for the exact reasons you said.

Re: Phoenix 1.0

#146
post #65

Earlier quoted context omitted.

This doesn't compare to the frameworks you mentioned in that regard. It's a framework for the Elixir language, not another JS framework.

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.

Re: Phoenix 1.0

#147

Earlier quoted context omitted.

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…

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 exports, rather than on its true a priori merits. Some languages are designed for intense extensibility and expressiveness, like Forth. An argument based on laundry listing abstractions to dissuade someone from using it would be rightfully dismissed as nonsense, since it is their prerogative to define the threshold of abstraction they need.

Furthermore, I've noticed that people who tend to promote languages based on the mere reductionist listing of abstractions tend to not understand those abstractions well themselves, treating it as dark wizardry.

Erlang is definitely malleable to reasonable extensibility. See Erlando which adds Miranda/Haskell-like monadic patterns to Erlang.

Re: Phoenix 1.0

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

Elixir can be optionally typed with the Dialyzer which will bring you to about the same level of static typing as go (if not more because the dialyzer allows for generics).
Post reply on HN