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

211–220 of 228 posts

Re: Phoenix 1.0

#211

Post by lobster_johnson »

sasa555 wrote: post #94
mands wrote: post #61

Slightly off-topic, but can someone familiar with both Elixir and Erlang explain what Elixir provides in comparison to Erlang. I'm looking into using Erlang for a new project that requires extensive scaling and concurrency and am coming from a functional background so may be more comfortable with the traditional Erlang syntax. However it seems that perhaps more development and activity is happening on the Elixir side…

I've been doing full-time Erlang for five years, and I personally prefer Elixir. Elixir is semantically close to Erlang the language, and allows you to take advantage of all the great benefits of Erlang/OTP. It's benefit is dev's productivity. Creating OTP applications and releases is simpler, and there are tools in the language (e.g. macros, polymorphism via protocols, tidier stdlib), and around it (e.g. Hex package…

My impression is that Erlang/Elixir is excellent at the kind of decentralized networked services that people usually use it for, but less ideal for many other things. What's your experience with Erlang as a "day to day" language for more mundane stuff?

For example, a lot of my work tends to revolve around working with data. Processing large batches of data, parsing (often it comes in the shape of XML), transforming, filtering, ingesting it into databases, and so on. I can do this easily in Ruby, but performance issues has driven me to use Node.js or Go for new projects. With Go it's ridiculously easy to build efficient pipes that can parallelize each step to my liking, backpressure included. It's also trivial to build small command-line tools as well as specialized daemons. I have a world of libraries (and bindings to C libraries) at my disposal: AWS, image processing, transcoding, PostgreSQL, XML, JSON, it's all there. Go is also decent at Unicode and string manipulation.

I'm not wild about Go's performance, and everything I have seen of Erlang indicates that its performance is closer to that of Ruby or Node.js. Any comments here? Whenever I need to fire up anything related to batch processing in Ruby or Node.js, things take forever. Erlang's advantage here might be that it's easier to spawn remote processes to parallelize the workload.

Re: Phoenix 1.0

#212

Post by davelnewton »

jeremyjh wrote: post #199
davelnewton wrote: post #182

Earlier quoted context omitted.

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

I'm pretty familiar with actually-good type systems, and as I've attempted to say, they do eliminate certain classes of problems. They just don't happen to be the types of problems I struggle with or find major productivity-burners. YMMV.

Orthogonal to all this is that I'm underwhelmed by Go's type system :/ If I was going to shoot for a language whose type system really helped me (in the ways I need/want help) it wouldn't be Go. It's pretty slick for some things (aesthetics aside) though.

Re: Phoenix 1.0

#213

Post by davelnewton »

Havvy wrote: post #202
fghfghgfhfg wrote: post #188

Earlier quoted context omitted.

The type system, at least more powerful ones, encode a lot of intention and more importantly, enforce it. It might add some additional complexity in the first writing of the code, but in return you eliminate whole classes of problems forever. It's not just the initial writing that benefits (at some cost, admittedly), but all future changes won't have those problems either. In the case the types themselves need to cha…

If you're talking about a good type system, sure. The type system in Go is frankly terrible at describing the kinds of invariants and reuse we care about. I'd dare say that diaylizer (Elixir's optional but easy to use type system) would lead to more maintainable code than Go's forced type system in the long run.

That more or less sums up my view on Go in a nutshell.

Re: Phoenix 1.0

#214

Post by bpicolo »

15155 wrote: post #207
bpicolo wrote: post #173

Earlier quoted context omitted.

You can handle misspelled variables/bindings/function names in Ruby/Python/JS by linting. That's a class of errors that's easy to avoid anywhere with a good text editor.

Due to the extremely dynamic nature of Ruby, I'm not aware of any linter that can catch misspellings when interacting with class or instance variables, dynamically-defined methods, etc. It's an entirely different level of statically-verifiable correctness.

I know of class/instance variables working for py linters. Dynamically-defined methods, no, but those are hard to reason about even for humans so it's best to avoid them entirely.

Re: Phoenix 1.0

#215

Post by flackjap »

nox_ wrote: post #201
klibertp wrote: post #197

Earlier quoted context omitted.

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.

I have rarely read things that were that much wrong. Just because the code can be represented as a data structure, or just because the compiler is written in its own language, that doesn't make a language homoiconic.

I concur -> In computer programming, homoiconicity (from the Greek words homo meaning the same and icon meaning representation) is a property of some programming languages in which the program structure is similar to its syntax, and therefore the program's internal representation can be inferred by reading the text's layout. Wiki

Re: Phoenix 1.0

#216

Post by flackjap »

bbatha wrote: post #148
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...

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

With compile time checking that is already there + Dialyzer, you basically have the whole 'code correctness' side of static typing? Right?

Re: Phoenix 1.0

#217

Post by klibertp »

flackjap wrote: post #215
nox_ wrote: post #201

Earlier quoted context omitted.

I have rarely read things that were that much wrong. Just because the code can be represented as a data structure, or just because the compiler is written in its own language, that doesn't make a language homoiconic.

I concur -> In computer programming, homoiconicity (from the Greek words homo meaning the same and icon meaning representation) is a property of some programming languages in which the program structure is similar to its syntax, and therefore the program's internal representation can be inferred by reading the text's layout. Wiki

Every language's syntax internal representation can be inferred by reading it's text layout. It's what parsers do and people can, too.

How "similar" internal representation needs to be to its textual version to be homoiconic is subjective.

In Erlang an expression:

    2+3.
yields this AST:

    {op,1,'+',{integer,1,2},{integer,1,3}}
You can strip line and type annotations (you could also easily add them to the Prolog example below), which will get you:

    {'+', 2, 3}
If you scroll down the Wiki page you cite, you'll see an example in Prolog, where this:

    X is 2*5
yields AST of this shape:

    is(_, *(2, 5))
The important similarity here is that all elements of ASTs are still first class objects in the language. You can manipulate them in their raw form with the same functions you'd use for manipulating any other data. In other words, once you have an AST, you don't need to evaluate it, it's enough to just read it.

This is not true for Python. An expression:

    2+3
yields:

    Expression(body=BinOp(left=Num(n=2), op=Add(), right=Num(n=3)))
An AST here cannot be manipulated in its raw form here. To manipulate it - the representation itself - you'd have to parse it again or evaluate it to use special methods on AST objects.

So this is the practical definition of homoiconicity I came up with. You are of course free to disagree. I'm stressing "practical" here, because what I'm interested in is how easy it is to manipulate the AST to write macros. Homoiconicity for the sake of homoiconicity is of no interest to me.

PS. BTW, maybe I should base my argument on Lisp instead of Prolog. If you read the Wikipedia page carefully you'll see the part on Lisp says the same thing I do above.

Re: Phoenix 1.0

#218

Post by simoncion »

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.

AFAIK, bytecode compiled on one Erlang system runs on any other. Bytecode is stored in .beam files, and -AIUI- .beam files are always forward compatible.

However, I'm not sure if bytecode compiled with an Erlang version >=17.0 will run on earlier versions of Erlang if it makes use of maps. (Maps are a new type that was introduced in Erlang 17.0.) I should really test this.

Re: Phoenix 1.0

#219

Post by lobster_johnson »

rubiquity wrote: post #139
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 used both Go and Elixir so here's my thoughts: Elixir/Erlang aren't your typical dynamic language. Elixir is compiled and has pattern matching. I catch a ton of bugs at compile time in Elixir that I would never catch in Ruby/Python/JS until runtime. Examples of these are misspelled variables/bindings/function names and pattern match that will never actually match. Those are really, really common time wasters all…

Pattern matching will only get you so far without static analysis, though?

For example, if I have a function that returns {foo}, and I change it to return {foo, bar}, then a pattern match on its return value that does {Foo} -> ... will fail at runtime, and the compiler won't pick it up, right?

In a statically type language (such as Go), changing the number (or type) of return values will result in compilation errors until all callers have been updated.

Re: Phoenix 1.0

#220

Post by rubiquity »

danneu wrote: post #189
rubiquity wrote: post #132

Earlier quoted context omitted.

I know you're being downvoted but I 100% agree with you. I don't want 100,000 Hex packages. I want a few thousand packages that solve problems really well and people rally around and collaborate on them. NPM and RubyGems are casualties of people seeking open source fame and I hope we can avoid that in Elixir.

> NPM and RubyGems are casualties of people seeking > open source fame and I hope we can avoid that in Elixir. No, they're casualties of people actually using the platform, the platform's low publishing barrier, and the ecosystem's preference for focused libraries over monolithic bouncy castles. Rallying around one library sounds cool until you see that the top three competing solutions in another ecosystem each have…

Yeah because those 20+ half-baked MongoDB drivers on npm are totally better than emongo (Erlang) and mongo (Elixir).
Post reply on HN