Comment by vezzy-fnord | Hacker News Reader

Comment by vezzy-fnord | Hacker News Reader

Parent Full thread

I think part of it is that with Erlang it is not as easy to get up and running with a new website.

I'm doing this at present and there is no special difficulty.

And things like package management, build tools, meta-programming, unicode handling and web frameworks are not as straight forward as in languages such as Ruby.

Erlang's module system means that a chunk of the raison d'etre behind language-specific package managers is already alleviated. The rest - dependency management and building, is handled quite well by tools like Rebar. One can also leave Rebar as a dependency tool strictly (which is its primary purpose anyway) and use whatever they like for a build system. Plain old Makefiles can work just fine, and it's not like most language-targeted build systems aren't some shiny variation of make, anyway.

Metaprogramming isn't quite as easy as in many OO languages, but it's hardly out of reach. The parser, the lexical scanner and other components are all exposed as Erlang modules, and there are projects such as the BossDB ORM that use parser transforms to provide features such as parameterized modules, which allow for using Rails-like ActiveRecord patterns, among other things.

Unicode handling? I think this might be a knock on Erlang's string handling. Strings are represented as iolists of Unicode points (integers) which goes with much of Erlang's philosophy in lists and tuples as being the prime data types. Space efficiency and real-world usage usually has strings passed as binaries, but most web frameworks and libs can handle them plainly nonetheless.

Web frameworks? Chicago Boss for a Rails-like, Nitrogen and N2O for real-time and extremely high load applications, or even just plugging in to web servers like Cowboy or Yaws can be enough for a RESTful backend.

> Erlang's module system means that a chunk of the raison d'etre behind language-specific package managers is already alleviated.

Sure, modules provide a way to "package" functions, but that is 5% of what a package manager does. Being able to distribute, fetch and do dependency resolution is certainly the bulk of it.

I definitely prefer my deployments to rely on packages than fetching git repositories from Github and Bitbucket. There are recent discussions in Erlang mailing list regarding packages and the OTP team (the team behind Erlang) is looking into package managers too.

> The rest - dependency management and building, is handled quite well by tools like Rebar.

Sorry, Rebar does not handle dependencies well. Rebar does not even guarantee repeatable builds. Once I fetch dependencies on my machine, my co-worker can end-up with versions different than mine and that is dependency management 101.

Rebar 3 seems to improve in this area but is still alpha. erlang.mk idea of package manager is a file on github in tsv format (and still no repeatable builds).

> Unicode handling? I think this might be a knock on Erlang's string handling.

Erlang needs better unicode support, regardless of using lists or binaries. Strings support only latin1 in literal format. If I want to write my name as a binary, it needs to be written as <<"paweł"/utf8>>. This is nowhere close to acceptable to anyone that has to write strings in formats other than latin1.

Things are getting better in Erlang 18 but there won't be any conveniences for handling unicode. There is no function to calculate the grapheme length (essential if you want to support languages like japanese or korean and do a size validation on an input), to convert to lowercase/uppercase and so on. Be it if the underlying representation is a list or a binary.

> Sure, modules provide a way to "package" functions, but that is 5% of what a package manager does. Being able to distribute, fetch and do dependency resolution is certainly the bulk of it.

Please God the Erlang/Elixir community don't invent another package manager. Pip, easy_install, gem, npm, composer, bundler, bower, maven and all the others I don't know about - we've got enough as users to remember the variations in syntax for. Let alone the duplication of effort in developing and maintaining the package managers, when their clever creators could be working on other problems.

You're too late ;)

Maybe someday someone will just create one package manager to rule them all, one that's not tied to a specific language, but can instead manage anything running on your computer.

Oh, wait.

https://hex.pm/

Rebar does not even guarantee repeatable builds

I think you're setting the bar a little high there. Reproducible builds is something that most package managers, OS and language-specific alike, struggle with to this day. Only Nix and Guix have complete solutions, I think.

Certainly Rubygems+Bundler in Ruby does it, as well as Mix in Elixir. npm in node.js may even do it due to its weird require system but I am not sure.

When I wrote "not as easy" I did not mean simply difficult. It just takes a bit more work with Erlang.

As for Erlang string handling: [175,95,40,12484,41,95,47,175] ;)

The good thing is that Erlang and Elixir can benefit from each other. For instance https://hex.pm which is made in Elixir, but can also be used for Erlang projects.

My point was to ask for clarification as to what said work entails and how it's larger than, e.g. Ruby or another mainstream platform for web applications.

I just tried running Chicago Boss. I followed the quick start guide that had a lot of steps and managed to get a 404 error.

With Rails there are less steps: gem install rails && rails new path/to/your/new/application && cd path/to/your/new/application && rails server and you just point your browser to http://localhost:3000 and get a nice welcome page for your new skeleton app.

Chicago Boss could be improved in that respect.

The reason for the 404 is because by default no action is bound to / in the proplists for the priv/<appname>.routes file. It tells you that quite succinctly. Explicitly heading to /greeting/hello works, as shown in the quickstart. Modifying the routes file is a good next step.

Your complaint boils down to there not being a pretty "Welcome" page. That could be addressed, but it's hardly a major concern.

No it is not how it looks it is that the documentation is lacking. The quick start didn't work for me. If it had been a simple page returning HTTP code 200 that just said OK, it would at least be something.

Sure you can make it work if you invest more time in it, but the point is that there are other platforms that have taken care to make it easier.

In general a lot of people seem to think that documentation is one of the biggest issues with Erlang.

Agreed - as simple as setting up yaws (which comes with a templating language built in!)

Reply on news.ycombinator.com