Hacker News Reader

Comment by chops | Hacker News Reader

The pmod arguments have been a pretty ongoing war[1] on the mailing list, especially since it was announced R16 would be removing official support for them.

With ChicagoBoss being one of the highest profile projects to use pmods extensively, Evan Miller has been arguing for them pretty extensively.

At least support wasn't completely dropped, since they are providing the parse_transform to re-enable the functionality:

https://github.com/erlang/pmod_transform

[1] A friendly war, anyway: http://erlang.org/pipermail/erlang-questions/2013-January/07...

View on HN

The fact that people like Evan Miller aren't taken seriously and heeded is why I only tinker with Erlang and haven't bothered to use it for anything.

Once they start taking the little people (so to speak) seriously, I'll revisit the Erlang runtime for an actual project.

Until then: Clojure.

Clojure has a strong tinkerer culture.

I think that Evan might object to being considered 'little' :-)

He's the one that named his framework "Chicago Boss" (after Tokyo Tyrant), not me. :P

I wish I could upvote this 5x. I love Erlang the language but, paraphrasing tarcieri (& zedshaw), the community around it can sometimes be a ghetto.

I think the problem is that Erlang does some things extremely well, which leads to people getting a bit smug about it, in a way that sometimes reminds me of "photography purists" sniffing at digital photography as being so very clearly sub-par, a few years ago.

My reality is that for a lot of the web stuff I do, the faster development time that Rails gives me is worth way more than a bit of speed / better use of resources. I don't need a redundant site with 0 downtime, I need to figure out if there's a market for what I'm working on, and/or pivot and add features as I begin to understand things better.

+1 for Chicago Boss, though, it's a solid effort that tries to push Erlang in some interesting directions. I do think I'll be using it for a project soonish, as the specs involve a lot of piping data around, and websockets, stuff that Rails is not as good at.

>as the specs involve a lot of piping data around, and websockets, stuff that Rails is not as good at.

I use Python in my day job and when I have need for something like that, I usually resort to Clojure. It's a pretty great experience.

Also look into Elixir if you're hellbent on using Erlang.

I'm pretty comfortable with Erlang, actually, having used it on and off for the past 9 years. Elixir looks cool, but a bit too experimental for what I'm working on. Chicago Boss makes me a bit nervous from that point of view too, for that matter... so we'll see what route we end up taking. Evan Miller, for the record, is really great about responding to bug reports and code ideas, so that is a big plus about the project.

The community is anything but a ghetto. Everyone I've interacted with is both highly intelligent, helpful, and very opinionated about the future of the language.

One of Erlang's strengths is its stability; they get their stability from being really picky about some things.

I think the community is open to change of the language, given that the idea you propose is a good one.

The thing that led tarcieri to write the "Erlang is a Ghetto" post was that he proposed the addition of Ruby-style blocks to the Erlang language. And then Richard O'Keefe wrote back a post—not a very diplomatic one—which explains why Ruby-style blocks is a horrendously bad idea to add to any language.

The main reason that Erlang sometimes comes along as smug is because there are some people in the community who are extremely capable in their fields of expertise. You need a good argument to convince a semanticist that your informally specified language extension is worth anything, unless you can supply meta-theorems which explains why. Or at least provide proper semantics. In other words, you need a really good design.

If you have working code for your design, it is even better. If you have an EEP (Erlang Enhancement Proposal) you may even have your idea implemented. There is, for instance, an EEP called "Named funs" which extends and generalizes tarcieris proposal. It did not go in in time for R16, but it is still being worked on.

Parameterized modules were an experiment. Like Tuple funs (now removed), packages (now removed), and mnemosyne (now removed). They still live on outside the Erlang distribution but retains enough inside to support them via parse transformations.

> Richard O'Keefe

Heh, interesting. That brings up this interaction, which I feel characterizes some of the problem:

http://erlang.org/pipermail/erlang-questions/2013-January/07...

Loïc's response to him is worth quoting:

" You are confronted with the problem of wasting a lot of time writing basement level code to access and update deep values. You think "Great! I can write DSL or combinators to solve this!". Now you got two problems, and you haven't come any closer to solving the first one. The DSL still maps to functions which needs to access and update these values, and that code is still painful to write. Your next step is to think "Great! Let's generate all that code then!". Now you got three problems, and you better hope to have not made any error when writing that code generator or you'll waste a lot more time. Speaking of time, by the time you get to that point the PHP developer has already long finished his bug-free implementation of the same code and is moving on to other tasks."

There's been countless arguments against PMods, mostly about their implementation, not the concept itself.

Here's a list of a few I have compiled on the mailing list in the past: http://erlang.org/pipermail/erlang-questions/2012-August/068...

Evan has a point regarding the verbosity of many expressions and there have been very complete enhancement proposals that are much better in what they cover and their properties. See for example Richard O'Keefe's 'Frames' proposal: http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf

This doesn't mean his points and concerns are not valid, and it also doesn't mean that parametrized modules should stay. I think the compromise made (still support them, but not in the main OTP distribution) is a decent one, because it takes little effort to keep old code compatible, stuff still works, but the issues mentioned in my post linked above are no longer a concern of whoever is using or implementing libraries with features that were built on a weird implementations like tuple calls.

It also allowed a much simpler error handler with new very interesting mechanisms when similar features were cleaned up.

I think you have it wrong, in my humble opinion.

Erlang is not a tinkerers language. If you want to tinker you want Scheme, Clojure or Haskell, which to a far greater extent plays around with new ways of doing things in programming languages.

Erlang is about providing a stable platform and controlled additions. The decision to remove parameterized modules must be balanced against the fact that you are maintaining an experimental extension and that it complicates the compiler. So the decision was made to remove them completely from the language in order to pave the way for a better solution.

One of Joe Armstrongs ideas is that if you add a new feature to the language, you must remove one as well. So the choice is all about balancing the effort required to keep parts of the implementation working.

It isn't that Evan Miller as not been heard and taken seriously. Believe me, the decision is not a quick one made just for the sake of making such a choice.

In Erlang, pmods are problematic because the language has no type system and they seriously mess with readability of program code. They also make it harder to grep in code, and there are very simple ways to work around the lack of them. And they are not the feature we need to make the language better. There are a large amount of other features which would be far better to have.

I'm well aware of the technical merits of the decision and generally agree with it (I upvoted you because of the clear explanation, btw). What rubs me the wrong way are comments like (emphasis mine):

"And they are not the feature WE need to make the language better"

and

"Looking over Elixir, I tend to agree with Tristan -- it seems to have all the syntactic sugar that creative, non-hardcore, easily frightened developers might like"[0]

Which translate to: just go away, please.

[0] http://erlang.org/pipermail/erlang-questions/2013-January/07...

You seem to have forgotten to quote the next paragraph which says, "In seriousness, it looks like a nice language -- I wonder if it, or the Ruby, Python, JavaScript "front-end" toolsets, might be a better fit for extending Erlang applications to programmers who are looking for a kinder, gentler syntax?"

Garret spends a fair amount of energy trying to make Erlang more accessible.

http://e2project.org/erlang.html http://www.erlang-factory.com/conference/SFBay2013/speakers/...

You're approaching this wrong; they do take the little and big people seriously. It's also a 20(?) year old language with a lot of features! You can't possibly add/remove everything everyone wants - I think the team behind Erlang is doing an exceptional job of maintaining stability while getting new features and cleaned up releases out.

Also - my own startup uses Erlang extensively (we use Riak, yes, but our actual application is built on top of Erlang too); I would say 80% of our codebase consists of Erlang. It's rock solid and the concurrency and distribution features (and ease of use) are unmatched. Also - OTP, nothing compares to OTP yet (Akka is trying to get there, but they have a long journey ahead of them).

I've been trying to learn a little erlang for a while. One of the things that holds me back is the external libraries. If it's a part of erlang/OTP, then great, usually I'm happy with it.

But it's hard to find, install, and update external libraries compared with many other languages (like haskell/cabal, ruby/gems, etc.). How do you deal with that on a practical level?

There isn't a central clearing house at the moment. But the conventions is to use a tool called "rebar" and you simply add a dependency in your rebar.conf like

{cowboy, ".*", {git, "git://github.com/extend/cowboy.git", "master"}}

and then it will use cowboy's rebar.conf to download what it requires, in this case ranch. So, you can just link to the top level library you care about it most cases and let rebar deal with it.

Oh, I see. Thank you.

After asking around on IRC, I found out about CEAN, which looks like it's trying to be a central clearing house. But it's a little strange looking compared to ones that I'm used to... it doesn't look very community-oriented. I couldn't even find a license file for CEAN itself.

But it looks like rebar offers a lot already, so I'll look into that more.

Oh wow. I didn't know you were doing Erlang these days. (You know me as StoneCypher.)

Welcome to the flock. You're a very good programmer, assuming you're the person that I knew from efnet #c++, and the community will be improved for having you around.

Reply on news.ycombinator.com