Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir – The next big language for the web

creativedeletion.com

Post reply on HN
Print view View original

31–40 of 85 posts

Re: Elixir – The next big language for the web

#31

Post by lectrick »

yellowapple wrote: post #24
adamkittelson wrote: post #21

Earlier quoted context omitted.

I used Weber when I first got into Elixir a little over a year ago. It was a cool framework and I even contributed to it (mostly keeping it up to date as new versions of Elixir were released). But... the last commit was 9 months ago. Weber is dead. If you're interested in doing web stuff with Elixir today Phoenix is what you want. http://www.phoenixframework.org/

Now would be a good time to plug Sugar, another framework for Elixir that's in active development. http://sugar-framework.github.io/ (disclaimer: I'm one of the collaborators on the project)

Good luck! I think this is a great time to start a new Elixir framework, and competition (or perhaps, "coopetition") is good.

Re: Elixir – The next big language for the web

#32

Post by pawelkowal »

vezzy-fnord wrote: post #18

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

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

Re: Elixir – The next big language for the web

#33

Post by dragonwriter »

pbowyer wrote: post #25

Given some were touting Go as the next big language what - 12-18 months ago - can anyone enlighten me why Elixir would be different to Go. Or where Go didn't live up to its promises?

> Given some were touting Go as the next big language what - 12-18 months ago - can anyone enlighten me why Elixir would be different to Go.

Its a completely different language, with a completely different set of people thinking it is the way to go going forward. They have very little in common.

> Or where Go didn't live up to its promises?

As there are in the present, there will probably be more than one significant web application language in the future. Its not impossible that Go and Elixir could both be among them. Its not really an XOR type of situation.

Re: Elixir – The next big language for the web

#34

Post by laut »

vezzy-fnord wrote: post #18

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

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.

Re: Elixir – The next big language for the web

#35

Post by lectrick »

pbowyer wrote: post #25

Given some were touting Go as the next big language what - 12-18 months ago - can anyone enlighten me why Elixir would be different to Go. Or where Go didn't live up to its promises?

Some of this is opinion, but I looked at Go and didn't like its exception model (or total lack thereof). Checking for errors after every possible bit of code that could go wrong seemed like an ugliness to me (disclaimer: beauty is in the eye of the beholder, and I'm certain a Go guy will chirp up here in its defense... which is fine!).

Elixir/Erlang almost couldn't be more different in this regard, which basically embrace runtime failures (things fail, so... "Let it fail quickly"). An uncaught runtime error in Elixir/Erlang causes the node to shut down after logging the error and, if it has a supervisor node (which is quite likely), the node is restarted in a fraction of a microsecond. The developer is expected to monitor the logs and watch for common faults and fix those. This is in fact where the "nine nines" reliability comes from- restarting nodes extremely quickly after runtime errors.

The Erlang philosophy is basically, "these systems exist in the real world, which is sometimes unpredictable and flaky... accept it and allow the code to move on quickly." This happens to be a good strategy for website code- Remember that Erlang was built to run cell networks... How often are cell networks down these days?

I was also a "disenfranchised" Ruby guy, tired of working on classes of bugs that would never even see the light of day in a functional language, which is why Elixir's syntax was appealing (I had already looked at Erlang, but I didn't like its syntax). Again, there's taste and opinion here, of course. Coding has become awfully fashion-driven, of late.

There's a class of programmers who don't care about syntax or don't see the point of it. Ruby/Rails folks are not typically that type of programmer, and that's the first group who will likely migrate to Elixir.

Finally, what really raised my eyebrows about Elixir was its macro facility http://elixir-lang.org/getting-started/meta/macros.html Prior to Elixir, full-fledged macros were only a feature of homoiconic languages (the Lispy ones where the syntax is also a data structure). Elixir came up with a clever way to do macros, while retaining syntax.

Re: Elixir – The next big language for the web

#36

Post by vezzy-fnord »

pawelkowal wrote: post #32
vezzy-fnord wrote: post #18

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

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

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.

Re: Elixir – The next big language for the web

#37

Post by vezzy-fnord »

laut wrote: post #34
vezzy-fnord wrote: post #18

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

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.

Re: Elixir – The next big language for the web

#39

Post by pron »

lectrick wrote: post #27
pron wrote: post #16

Not about Elixir specifically, but don't people get tired of switching languages? What, people will now have to port all Ruby libraries to Elixir (or, at the very least, relearn them), and then a few years down the line to the next thing? Isn't this a huge waste of effort? Not to mention the poor CTO who gets a job at such an early-adopter company in 15 years, and finds out the codebase is made up of 7 different lang…

> Not about Elixir specifically, but don't people get tired of switching languages? Are you a developer because you don't want to keep learning? Maybe you walked into the wrong room? ;) > What, people will now have to port all Ruby libraries to Elixir (or, at the very least, relearn them), and then a few years down the line to the next thing? Isn't this a huge waste of effort? In this case, Elixir actually has a sell…

> Are you a developer because you don't want to keep learning? Maybe you walked into the wrong room? ;)

Don't you rather be learning new concepts rather than new syntax/APIs? Not that Elixir doesn't bring new concepts to Ruby developers (it does), but even so, I think switching a language for production code has a terrible cost/benefit ratio compared to learning a new algorithm or even a new approach without switching a language.

Since when has "learning" in CS meant adopting a new language?

Re: Elixir – The next big language for the web

#40

Post by jtwebman »

filereaper wrote: post #28

I've been monitoring Elixir on HN for a while now, looks like an interesting direction to take. I wanted to know which direction Elixir is going to take? Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir? Is there a plan to change Rails enough to run on Elixir? How does the community feel about Elixir? I'm certainly interested in the concurrency aspects of Elixir (ie. no G…

Rails is just one way to solve data problems. I don't see Rails being written in Elixir as it is not a functional way to solve that problem. Nothing against rails it is a good way to solve the problem in a modern object oriented way though Active Record has it's issues as well.
Post reply on HN