11 ms·

The Unix Philosophy and Elixir as an Alternative to Go

305 points by aaron-lebo 11y ago

applecore 11y ago
> However, as we more and more turn servers into REST APIs that are supposed to deliver JSON to numerous clients, for many it is time to find an alternative. Perhaps the alternative isn't more REST APIs that deliver JSON; given its inherent problems, it's more likely we'll be using a challenger to that entire model, like GraphQL. https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html https://facebook.github.io/react/blog/2015/05/01/graphql-int...
- jtwebman 11y ago
  I willing to bet once the spec is out there will be a Elixir implementation of GraphQL. I am also willing to bet Elixir would still be faster then Node.js, Ruby, or Python for that.
oldpond 11y ago
Thanks for that interesting viewpoint. I have also done the same survey, and I agree. I did a ChicagoBoss PoC last year, and Elixir and Phoenix are my goto for the next one. It should also be noted that both are young languages and they are evolving rapidly. This makes them even more exciting to me. Also, I think Go's sweet spot may be a new approach to client/server i.e. applications that work across the network. This is quite different than the browser/app server model. Elixir has similar plumbing that fit this model as well, but what really excites me about Elixir and Phoenix is the ability to build a restful MVC application that can take advantage of Erlang/OTP's scalability.
- vezzy-fnord 11y ago
  It should also be noted that both are young languages and they are evolving rapidly. Erlang itself is nearly 30 years old, but it wasn't open sourced until 1998. OTP came shortly after. Erlang doesn't evolve rapidly at all (at least, not in the typical sense of "Software innovates so quickly - Last year I was using one event loop, and this year another"!). It's remarkably conservative, yet still ahead of the pack. That's what makes it so great.
  - lostcolony 11y ago
    He was talking about Elixir and Go. Not Erlang.
    - issaria 11y ago
      He might intentionally ignored Elixir, IMO.
- aikah 11y ago
  > It should also be noted that both are young languages and they are evolving rapidly. Go will basically get dynamic linking and stop evolving. Its type system is way too simple to support any new significant feature. And go designers have said many time that the language is "done".
  - Dobbs 11y ago
    My understanding is not that they have said that the language is "done", but that the 1.0 branch is stable and won't get any new major language features. At somepoint they will start rolling out 2.0 and it will have new features, maybe even generics. But why should they worry about that the language is plenty good as it stands for developing and their is plenty of work to do on cleaning up build systems, runtime, gc, etc.
    - aikah 11y ago
      > "The language is done and that's a good thing," Buberel says. http://finance.yahoo.com/news/google-thinks-knock-one-oracles-233951894.html http://finance.yahoo.com/news/google-thinks-knock-one-oracle... Pike said exactly the same thing(video is on youtube), another Go guy said exactly the same thing in a podcast ... So yes, Go language is DONE, period. > But why should they worry about ... They don't, however people adopting Go and wanting generics shouldn't be tricked into thinking that Go developers are even considering generics , because they are not. If they invest in Go, they should know that they aren't going to get generics at all. As for what the Go team thinks, it doesn't really matter they are not betting their own startup on Go. > they will start rolling out 2.0 and it will have new features where did you get that idea? it is impossible to add significant new features without breaking backward compatibility, do you really think Go designers are ready to go that way? of course not. But i'm curious what led you to think that ?by all means, give me official sources like I just gave you.
      - Gigablah 11y ago
        Nothing in the future is set in stone. I'm curious why you're so sensitive about this issue.
vezzy-fnord 11y ago
Erlang (and by extension Elixir) are good languages for web development, I agree. Frameworks like Nitrogen and N2O even let you do frontend work directly from base Erlang constructs like records and functions to represent templates and JS callbacks, respectively. However, they will not replace Go for a rather simple reason. Erlang is an application runtime first and a language second. It's not meant to play with the native OS all that well, instead relying on its own scheduling, semantics, process constructs and the OTP framework. It exports a minimum set of OS libs for things like file system interaction, but you wouldn't write a Unix subsystem daemon in it. Though, you certainly can - if you want to hack with NIFs, port drivers and C nodes. But then you put the global VM state at risk if some native caller blows up. For this reason, Go will remain a dominant choice for infrastructure and systems programmers. It definitely is replacing C/C++ for lots of things above kernel space, contrary to your statement. I'd honestly dispute the characterization that Elixir is a small language. Erlang is easier to fit into your head, not least of which is because of how essential pattern matching on tuples and lists is. It's a consistent and homoiconic design, more warty constructs like records aside. Finally, Erlang/Elixir aren't Unix-y at all. Don't get me wrong, BEAM is a wonderful piece of engineering. But it's very well known for being opinionated and not interacting with the host environment well. This reflects its embedded heritage. For example, the Erlang VM has its own global signal handlers, which means processes themselves can't handle signals locally unless they talk to an external port driver.
- rubiquity 11y ago
  > However, they will not replace Go for a rather simple reason. Erlang is an application runtime first and a language second. It's not meant to play with the native OS all that well, instead relying on its own scheduling, semantics, process constructs and the OTP framework. I think you could argue that both languages are equally a pain in the ass to interop with C in. Erlang/Elixir is slightly more complex because you do need to keep the ERTS schedulers in mind, but whens the last time you saw someone give cgo a compliment? > It exports a minimum set of OS libs for things like file system interaction, but you wouldn't write a Unix subsystem daemon in it. Though, you certainly can - if you want to hack with NIFs, port drivers and C nodes. But then you put the global VM state at risk if some native caller blows up. Usually Ports are the first line of attempt to not have to write a NIF in the first place. > Finally, Erlang/Elixir aren't Unix-y at all. I'm guessing what OP means by "Unix-y" is the metaphorical definition of Unix-y as in the oft-butchered Unix philosophy of small composable programs that operate on streams of data rather than playing by all of Unix's rules. Elixir very much satisfies this definition with its emphasis on functional programming and pipe operator.
jtwebman 11y ago
I have been using Elixir for a while now! I'll never go back to Go or Node.js by choice.
- bhrgunatha 11y ago
  Out of interest - why not?
  - jtwebman 11y ago
    1. Readability is probably the biggest reason. I don't have to worry that some base object changing what I am thinking is happening. There is little magic and it is easy to follow. 2. Let it fail, elixir and erlang you have to write code assuming it is going to fail and handling when it does. Most other language you have to write that code all over in your logic code. Elixir and erlang you do not (readability again). 3. OTP! There is a great distributed framework that erlang and a bunch of much smarter then me programmers built over the last 20 year that I just get to use. Also you can send functions and code over the wire as well to run. Making some very interesting things that are just impossible to do in other languages. These are just a few reasons. I do build mostly build web applications for business apps. So because of that this is a really good fit. I don't think it is the answer to all but it has been expanding fast. The one thing I wish it had would be that your dependencies were yours only. I think this is one of the big reasons Node.js got successful so fast. In node you can run different versions with-in the same app depending on the libraries. Elixir is more like ruby in that you can only have one. Well you can have two for swapping out without down time but that is it. I do think this is one of the limits to the Erlang VM.
    - Skinney 11y ago
      > Also you can send functions and code over the wire as well to run. Making some very interesting things that are just impossible to do in other languages. Well, you could do this in any language that has 'eval' really, which includes most dynamic languages. Unless you're referring to something else?
andyl 11y ago
Elixir and Phoenix are great for web-apps, REST API's and the like. Phoenix channels make real-time push super simple and scalable.
stefantalpalaru 11y ago
Surprisingly favorable benchmark: https://github.com/mroth/phoenix-showdown https://github.com/mroth/phoenix-showdown and related HN discussion: https://news.ycombinator.com/item?id=8672234 https://news.ycombinator.com/item?id=8672234
- pella 11y ago
  other benchmark : https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
- chrismccord 11y ago
  It gets even more interesting on bigger hardware. A user ran the benchmarks on a 10 core Xeon, Phoenix got 180,000 req/s and peaked at 75% CPU, so IO was still the bottleneck. We were also able to have ~600µs average latency with that load. https://gist.github.com/omnibs/e5e72b31e6bd25caf39a https://gist.github.com/omnibs/e5e72b31e6bd25caf39a
jordan0day 11y ago
I think Elixir and Go solve different problems -- but for the problem space the author mentions here, web services, Elixir is clearly superior.
joshbuddy 11y ago
Web workers are real concurrency and afaik, there is no GIL that spans across the main thread and the worker threads in any of the browser implementations of web workers.
- rubiquity 11y ago
  The limitation with Web Workers is that the main worker thread is the only one that can interact with the DOM.
  - codesushi42 11y ago
    Why would you want multiple threads touching the UI? Android processes for instance only have one UI thread.
    - rubiquity 11y ago
      Updating is different than reading. Having concurrent reads would be a good thing.
      - codesushi42 11y ago
        I do not see a big benefit from that. Reading from the DOM will already be fast and can be handled in one thread. And you won't have concurrent reads if another thread is writing to the DOM. I think the designers of web workers made this decision thoughtfully. Other environments like iOS and Android only have one UI thread as well.
aikah 11y ago
> That being said, have you tried writing a web app in Go? You can do it, but it isn't exactly entertaining. All those nice form-handling libraries you are used to in Python and Ruby? Yeah, they aren't nearly as good. You can try writing some validation functions for different form inputs, but you'll probably run into limitations with the type system and find there are certain things you cannot express in the same way you could with the languages you came from. Database handling gets more verbose, models get very ugly with tags for JSON, databases, and whatever else. It isn't an ideal situation. I'm ready to embrace simplicity, but writing web apps is already pretty menial work, Go only exacerbates that with so many simple tasks. This. And don't even try to work around these limitations and share your work for free, or you're going to get trashed by the Go community( i.e. the Martini fiasco ) But think of go more as a blueprint. Go has great ideas(CSP,go routines,...) Hopefully it can inspire a new wave of languages that don't rely on a VM, that are statically typed and safe without a fucked up syntax. The language that succeeds in striking the right balance between minimalism and features with an excellent support for concurrency will be the next big thing.
- bsder 11y ago
  > ( i.e. the Martini fiasco ) Reference please for those of us who are only casual Go users?
  - Gigablah 11y ago
    The author of Martini released his framework, some people in the community said it wasn't idiomatic Go, he agreed and eventually released another one called Negroni. I don't know if he was "trashed", or whether there was a "fiasco".
    - enneff 11y ago
      Jeremy Saenz certainly remains a well respected member of the Go community. Martini is very 'magical' and makes it hard to see exactly what's going on, making it quite unusual as a Go framework, so naturally it drew some criticisms. After some experience with the library, Jeremy realized that he actually needed a lot less to do what he wanted, so he wrote Negroni.
4ydx 11y ago
Models get ugly with tags? You don't have to have them unless the names are different. This post is all about familiarity and the degree to which you are interested in using a language (just like every other post of its kind).
EdwardDiego 11y ago
> We've known for years that Ruby and Python are slow, but we were willing to put up with that. However, as we more and more turn servers into REST APIs that are supposed to deliver JSON to numerous clients, for many it is time to find an alternative. > You see a lot of competitors trying to fill this void. Some people are crazy enough to use Rust or Nim or Haskell for this work, and you see some interest in JVM based languages like Scala or Clojure (because the JVM actually handles threading exceptionally well), but by and far the languages you both hear discussed and derided the most are JavaScript via node and Go. Meanwhile the Java programmers just keep on delivering with Jersey, Spring, Restlet etc. etc. so forth. Less blogging, more doing.
- pjmlp 11y ago
  The problem with is that we don't live on the valley and are picky about losing features industry got to take from language research.
- dxhdr 11y ago
  No time for blogging, too much boilerplate to write!
  - EdwardDiego 11y ago
    Come now, we have IDEs for that. But seriously, Java users are not stuck in the 1990s, even if your gibes at its expense are, so perhaps you should revisit it. :)
    - vorg 11y ago
      Not just IDE's but also scripting languages like Groovy (the scripting version), its predecessor Beanshell, other less often used ones like Nashorn and Xtend, and even Clojure which doubles as a systems language. NB: By "Groovy (the scripting version)" I mean the component of Groovy which was Beanshell with closures and collections syntax added, but before the meta-object protocol was. So Groovy as used by Gradle rather than Groovy as used by Grails.
bsaul 11y ago
What about deployment ? How does it compare to "scp and i'm done" like in go ? Also what about memory usage ? My latest go service was a 4 mo file with one single json config file. It consumed less than 4 mo in RAM, which let me deploy it on a base 500Mo instance with plenty of memory to spare.
- dxhdr 11y ago
  I haven't used Elixir yet but deployment in Erlang isn't quite that simple, though it's not bad with some of the recent tools like relx. Just musing here but if you're dev environment is "scp and i'm done" then Elixir/Erlang are likely overkill for the problem at hand (Python or Ruby would probably work fine?). There is some base amount of complexity involved with working with BEAM but the features you gain in return are worth the trouble.
  - biokoda 11y ago
    "scp and i'm done" is completely possible with Elixir/Erlang. It is how we deploy lots of erlang pages. Copy beam files, have erlang check periodically if any beam files have changed and reload them. Using erlang releases is in no way mandatory.
    - dxhdr 11y ago
      Sure I suppose that's possible but it just seems a little gross. At least with 'scp binary' your first and all subsequent deploys use the same process so tools like Ansible can help you out. I guess that's what I was referring to -- repeatable deploys; pushing a new a BEAM release package is a more involved process than just with a single binary.
      - mmcclure 11y ago
        I totally agree, being able to just ship binaries around is fantastic. No complex process necessary, things Just Work™. However, if you're ok with a little extra process, Elixir allows for hot code reloads. To be fair, most use cases probably don't need it, but it's a pretty great option to have in your tool belt.
dschiptsov 11y ago
Erlang is well-researched, pragmatical language (read the Armstrong Thesis at last) this is why it is "great". User-level runtime, which is trying to do kernel's job is a problem, but relying on message-passing and being mostly-functional it, at least, have no threading/locking problems - so it scales. Nothing much to talk about. Go is also well-researched language with emphasis on keeping it simple and being good-enough and doing it right way (utf8 vs. other encodings) - a philosophy from Plan 9. Go has in it a lot of fine ideas, attention to details and good-enough minimalism - the basis for success. It is also pragmatic - that is why it is imperative and "simply" static-typed. Criticism about lack of generics or is not essential, especially considering that generics in a static typed language is an awkward mess. Complexity of its user-space runtime is a problem, of course, but runtime is hard, especially when it is not mostly-functional. Go is in some sense "back to the basics/essentials" approach, not just in programming but also in running the code, and even this is enough to be successful. BTW, its syntactic clumsiness and shortcomings (hipsters are blogging about) came from being statically typed, just admit it. On the other side, being C-like and already having C-to-Go translators opens up the road to static-analyzing and other tools. Go is the product of old-school (Bell labs) minds (like Smalltalk or Lisps) not of bunch of punks.)
- arthurcolle 11y ago
  Joe Armstrong's thesis, for the interested: http://www.erlang.org/download/armstrong_thesis_2003.pdf http://www.erlang.org/download/armstrong_thesis_2003.pdf
- biokoda 11y ago
  > User-level runtime, which is trying to do kernel's job is a problem, but being mostly-functional it, at least, have no threading/locking problems - so it scales. Nothing much to talk about. Spoken as someone who has never really used it. Dismissing it as nothing much to talk about is ridiculous.
  - dschiptsov 11y ago
    Erlang is "great". There is nothing much to talk about.
swagmeister 11y ago
>Finally, JavaScript handles the modern web well, but it isn't perfect. If a request does something that is especially CPU-heavy, every single user of your application will be waiting. One thing you might want to take into account is that ES2015 generators allow you to write long, blocking functions as generators that partially compute the result before deferring further computation to somewhere further along in the message queue. This allows you to spread out blocking computations so that you can still serve requests.
jbverschoor 11y ago
Important to note is that Elixir is created y Jose Valim from plataformatec. An important person and company in the Ruby community
georgeg 11y ago
I feel that this discussion would be incomplete without mentioning D-lang (http://dlang.org http://dlang.org) and the vibed framework (http://vibed.org http://vibed.org) as alternatives to the technology platforms that the author mentioned.
odiroot 11y ago
> Somewhere, however, that has been extrapolated to the idea that Go is a good language for writing web apps. I don't believe that's the case. I have always had this feeling and thought why isn't more people speaking up about that. For me it's a good improvement from C++ (and maybe C as well), somehow well-suited for systems programming. I never understood how people can claim it to be natural "upgrade" from Python or Ruby. I have a feeling the opposite is actually the case. This of course is all in the web-development context, not in general one.
fiatjaf 11y ago
Code samples side-by-side comparison: http://rosetta.alhur.es/compare/go/elixir/# http://rosetta.alhur.es/compare/go/elixir/#
prasoon2211 11y ago
I am utterly baffled by people who use the phrase "The Unix Philosophy" for justifying a piece of software but don't understand that Unix philosophy is in the context of software that can be composed together. That is why the other tenet of the Unix philosophy is to use text streams for all I/O.
vinceguidry 11y ago
Just keep using Ruby or, if you must, Node. Rails 5 is going to fit those use cases just fine. Web programming is entirely too complicated to roll your own stack unless you absolutely need to.

305 points by aaron-lebo 11y ago

> However, as we more and more turn servers into REST APIs that are supposed to deliver JSON to numerous clients, for many it is time to find an alternative. Perhaps the alternative isn't more REST APIs that deliver JSON; given its inherent problems, it's more likely we'll be using a challenger to that entire model, like GraphQL. https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html https://facebook.github.io/react/blog/2015/05/01/graphql-int...

jtwebman 11y ago
I willing to bet once the spec is out there will be a Elixir implementation of GraphQL. I am also willing to bet Elixir would still be faster then Node.js, Ruby, or Python for that.

oldpond 11y ago

Thanks for that interesting viewpoint. I have also done the same survey, and I agree. I did a ChicagoBoss PoC last year, and Elixir and Phoenix are my goto for the next one. It should also be noted that both are young languages and they are evolving rapidly. This makes them even more exciting to me. Also, I think Go's sweet spot may be a new approach to client/server i.e. applications that work across the network. This is quite different than the browser/app server model. Elixir has similar plumbing that fit this model as well, but what really excites me about Elixir and Phoenix is the ability to build a restful MVC application that can take advantage of Erlang/OTP's scalability.

vezzy-fnord 11y ago
It should also be noted that both are young languages and they are evolving rapidly. Erlang itself is nearly 30 years old, but it wasn't open sourced until 1998. OTP came shortly after. Erlang doesn't evolve rapidly at all (at least, not in the typical sense of "Software innovates so quickly - Last year I was using one event loop, and this year another"!). It's remarkably conservative, yet still ahead of the pack. That's what makes it so great.
- lostcolony 11y ago
  He was talking about Elixir and Go. Not Erlang.
  - issaria 11y ago
    He might intentionally ignored Elixir, IMO.
aikah 11y ago
> It should also be noted that both are young languages and they are evolving rapidly. Go will basically get dynamic linking and stop evolving. Its type system is way too simple to support any new significant feature. And go designers have said many time that the language is "done".
- Dobbs 11y ago
  My understanding is not that they have said that the language is "done", but that the 1.0 branch is stable and won't get any new major language features. At somepoint they will start rolling out 2.0 and it will have new features, maybe even generics. But why should they worry about that the language is plenty good as it stands for developing and their is plenty of work to do on cleaning up build systems, runtime, gc, etc.
  - aikah 11y ago
    > "The language is done and that's a good thing," Buberel says. http://finance.yahoo.com/news/google-thinks-knock-one-oracles-233951894.html http://finance.yahoo.com/news/google-thinks-knock-one-oracle... Pike said exactly the same thing(video is on youtube), another Go guy said exactly the same thing in a podcast ... So yes, Go language is DONE, period. > But why should they worry about ... They don't, however people adopting Go and wanting generics shouldn't be tricked into thinking that Go developers are even considering generics , because they are not. If they invest in Go, they should know that they aren't going to get generics at all. As for what the Go team thinks, it doesn't really matter they are not betting their own startup on Go. > they will start rolling out 2.0 and it will have new features where did you get that idea? it is impossible to add significant new features without breaking backward compatibility, do you really think Go designers are ready to go that way? of course not. But i'm curious what led you to think that ?by all means, give me official sources like I just gave you.
    - Gigablah 11y ago
      Nothing in the future is set in stone. I'm curious why you're so sensitive about this issue.

vezzy-fnord 11y ago

Erlang (and by extension Elixir) are good languages for web development, I agree. Frameworks like Nitrogen and N2O even let you do frontend work directly from base Erlang constructs like records and functions to represent templates and JS callbacks, respectively. However, they will not replace Go for a rather simple reason. Erlang is an application runtime first and a language second. It's not meant to play with the native OS all that well, instead relying on its own scheduling, semantics, process constructs and the OTP framework. It exports a minimum set of OS libs for things like file system interaction, but you wouldn't write a Unix subsystem daemon in it. Though, you certainly can - if you want to hack with NIFs, port drivers and C nodes. But then you put the global VM state at risk if some native caller blows up. For this reason, Go will remain a dominant choice for infrastructure and systems programmers. It definitely is replacing C/C++ for lots of things above kernel space, contrary to your statement. I'd honestly dispute the characterization that Elixir is a small language. Erlang is easier to fit into your head, not least of which is because of how essential pattern matching on tuples and lists is. It's a consistent and homoiconic design, more warty constructs like records aside. Finally, Erlang/Elixir aren't Unix-y at all. Don't get me wrong, BEAM is a wonderful piece of engineering. But it's very well known for being opinionated and not interacting with the host environment well. This reflects its embedded heritage. For example, the Erlang VM has its own global signal handlers, which means processes themselves can't handle signals locally unless they talk to an external port driver.

rubiquity 11y ago
> However, they will not replace Go for a rather simple reason. Erlang is an application runtime first and a language second. It's not meant to play with the native OS all that well, instead relying on its own scheduling, semantics, process constructs and the OTP framework. I think you could argue that both languages are equally a pain in the ass to interop with C in. Erlang/Elixir is slightly more complex because you do need to keep the ERTS schedulers in mind, but whens the last time you saw someone give cgo a compliment? > It exports a minimum set of OS libs for things like file system interaction, but you wouldn't write a Unix subsystem daemon in it. Though, you certainly can - if you want to hack with NIFs, port drivers and C nodes. But then you put the global VM state at risk if some native caller blows up. Usually Ports are the first line of attempt to not have to write a NIF in the first place. > Finally, Erlang/Elixir aren't Unix-y at all. I'm guessing what OP means by "Unix-y" is the metaphorical definition of Unix-y as in the oft-butchered Unix philosophy of small composable programs that operate on streams of data rather than playing by all of Unix's rules. Elixir very much satisfies this definition with its emphasis on functional programming and pipe operator.

jtwebman 11y ago

I have been using Elixir for a while now! I'll never go back to Go or Node.js by choice.

bhrgunatha 11y ago
Out of interest - why not?
- jtwebman 11y ago
  1. Readability is probably the biggest reason. I don't have to worry that some base object changing what I am thinking is happening. There is little magic and it is easy to follow. 2. Let it fail, elixir and erlang you have to write code assuming it is going to fail and handling when it does. Most other language you have to write that code all over in your logic code. Elixir and erlang you do not (readability again). 3. OTP! There is a great distributed framework that erlang and a bunch of much smarter then me programmers built over the last 20 year that I just get to use. Also you can send functions and code over the wire as well to run. Making some very interesting things that are just impossible to do in other languages. These are just a few reasons. I do build mostly build web applications for business apps. So because of that this is a really good fit. I don't think it is the answer to all but it has been expanding fast. The one thing I wish it had would be that your dependencies were yours only. I think this is one of the big reasons Node.js got successful so fast. In node you can run different versions with-in the same app depending on the libraries. Elixir is more like ruby in that you can only have one. Well you can have two for swapping out without down time but that is it. I do think this is one of the limits to the Erlang VM.
  - Skinney 11y ago
    > Also you can send functions and code over the wire as well to run. Making some very interesting things that are just impossible to do in other languages. Well, you could do this in any language that has 'eval' really, which includes most dynamic languages. Unless you're referring to something else?

andyl 11y ago

Elixir and Phoenix are great for web-apps, REST API's and the like. Phoenix channels make real-time push super simple and scalable.

stefantalpalaru 11y ago

Surprisingly favorable benchmark: https://github.com/mroth/phoenix-showdown https://github.com/mroth/phoenix-showdown and related HN discussion: https://news.ycombinator.com/item?id=8672234 https://news.ycombinator.com/item?id=8672234

pella 11y ago
other benchmark : https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
chrismccord 11y ago
It gets even more interesting on bigger hardware. A user ran the benchmarks on a 10 core Xeon, Phoenix got 180,000 req/s and peaked at 75% CPU, so IO was still the bottleneck. We were also able to have ~600µs average latency with that load. https://gist.github.com/omnibs/e5e72b31e6bd25caf39a https://gist.github.com/omnibs/e5e72b31e6bd25caf39a

jordan0day 11y ago

I think Elixir and Go solve different problems -- but for the problem space the author mentions here, web services, Elixir is clearly superior.

joshbuddy 11y ago

Web workers are real concurrency and afaik, there is no GIL that spans across the main thread and the worker threads in any of the browser implementations of web workers.

rubiquity 11y ago
The limitation with Web Workers is that the main worker thread is the only one that can interact with the DOM.
- codesushi42 11y ago
  Why would you want multiple threads touching the UI? Android processes for instance only have one UI thread.
  - rubiquity 11y ago
    Updating is different than reading. Having concurrent reads would be a good thing.
    - codesushi42 11y ago
      I do not see a big benefit from that. Reading from the DOM will already be fast and can be handled in one thread. And you won't have concurrent reads if another thread is writing to the DOM. I think the designers of web workers made this decision thoughtfully. Other environments like iOS and Android only have one UI thread as well.

aikah 11y ago

> That being said, have you tried writing a web app in Go? You can do it, but it isn't exactly entertaining. All those nice form-handling libraries you are used to in Python and Ruby? Yeah, they aren't nearly as good. You can try writing some validation functions for different form inputs, but you'll probably run into limitations with the type system and find there are certain things you cannot express in the same way you could with the languages you came from. Database handling gets more verbose, models get very ugly with tags for JSON, databases, and whatever else. It isn't an ideal situation. I'm ready to embrace simplicity, but writing web apps is already pretty menial work, Go only exacerbates that with so many simple tasks. This. And don't even try to work around these limitations and share your work for free, or you're going to get trashed by the Go community( i.e. the Martini fiasco ) But think of go more as a blueprint. Go has great ideas(CSP,go routines,...) Hopefully it can inspire a new wave of languages that don't rely on a VM, that are statically typed and safe without a fucked up syntax. The language that succeeds in striking the right balance between minimalism and features with an excellent support for concurrency will be the next big thing.

bsder 11y ago
> ( i.e. the Martini fiasco ) Reference please for those of us who are only casual Go users?
- Gigablah 11y ago
  The author of Martini released his framework, some people in the community said it wasn't idiomatic Go, he agreed and eventually released another one called Negroni. I don't know if he was "trashed", or whether there was a "fiasco".
  - enneff 11y ago
    Jeremy Saenz certainly remains a well respected member of the Go community. Martini is very 'magical' and makes it hard to see exactly what's going on, making it quite unusual as a Go framework, so naturally it drew some criticisms. After some experience with the library, Jeremy realized that he actually needed a lot less to do what he wanted, so he wrote Negroni.

4ydx 11y ago

Models get ugly with tags? You don't have to have them unless the names are different. This post is all about familiarity and the degree to which you are interested in using a language (just like every other post of its kind).

EdwardDiego 11y ago

> We've known for years that Ruby and Python are slow, but we were willing to put up with that. However, as we more and more turn servers into REST APIs that are supposed to deliver JSON to numerous clients, for many it is time to find an alternative. > You see a lot of competitors trying to fill this void. Some people are crazy enough to use Rust or Nim or Haskell for this work, and you see some interest in JVM based languages like Scala or Clojure (because the JVM actually handles threading exceptionally well), but by and far the languages you both hear discussed and derided the most are JavaScript via node and Go. Meanwhile the Java programmers just keep on delivering with Jersey, Spring, Restlet etc. etc. so forth. Less blogging, more doing.

pjmlp 11y ago
The problem with is that we don't live on the valley and are picky about losing features industry got to take from language research.
dxhdr 11y ago
No time for blogging, too much boilerplate to write!
- EdwardDiego 11y ago
  Come now, we have IDEs for that. But seriously, Java users are not stuck in the 1990s, even if your gibes at its expense are, so perhaps you should revisit it. :)
  - vorg 11y ago
    Not just IDE's but also scripting languages like Groovy (the scripting version), its predecessor Beanshell, other less often used ones like Nashorn and Xtend, and even Clojure which doubles as a systems language. NB: By "Groovy (the scripting version)" I mean the component of Groovy which was Beanshell with closures and collections syntax added, but before the meta-object protocol was. So Groovy as used by Gradle rather than Groovy as used by Grails.

bsaul 11y ago

What about deployment ? How does it compare to "scp and i'm done" like in go ? Also what about memory usage ? My latest go service was a 4 mo file with one single json config file. It consumed less than 4 mo in RAM, which let me deploy it on a base 500Mo instance with plenty of memory to spare.

dxhdr 11y ago
I haven't used Elixir yet but deployment in Erlang isn't quite that simple, though it's not bad with some of the recent tools like relx. Just musing here but if you're dev environment is "scp and i'm done" then Elixir/Erlang are likely overkill for the problem at hand (Python or Ruby would probably work fine?). There is some base amount of complexity involved with working with BEAM but the features you gain in return are worth the trouble.
- biokoda 11y ago
  "scp and i'm done" is completely possible with Elixir/Erlang. It is how we deploy lots of erlang pages. Copy beam files, have erlang check periodically if any beam files have changed and reload them. Using erlang releases is in no way mandatory.
  - dxhdr 11y ago
    Sure I suppose that's possible but it just seems a little gross. At least with 'scp binary' your first and all subsequent deploys use the same process so tools like Ansible can help you out. I guess that's what I was referring to -- repeatable deploys; pushing a new a BEAM release package is a more involved process than just with a single binary.
    - mmcclure 11y ago
      I totally agree, being able to just ship binaries around is fantastic. No complex process necessary, things Just Work™. However, if you're ok with a little extra process, Elixir allows for hot code reloads. To be fair, most use cases probably don't need it, but it's a pretty great option to have in your tool belt.

dschiptsov 11y ago

Erlang is well-researched, pragmatical language (read the Armstrong Thesis at last) this is why it is "great". User-level runtime, which is trying to do kernel's job is a problem, but relying on message-passing and being mostly-functional it, at least, have no threading/locking problems - so it scales. Nothing much to talk about. Go is also well-researched language with emphasis on keeping it simple and being good-enough and doing it right way (utf8 vs. other encodings) - a philosophy from Plan 9. Go has in it a lot of fine ideas, attention to details and good-enough minimalism - the basis for success. It is also pragmatic - that is why it is imperative and "simply" static-typed. Criticism about lack of generics or is not essential, especially considering that generics in a static typed language is an awkward mess. Complexity of its user-space runtime is a problem, of course, but runtime is hard, especially when it is not mostly-functional. Go is in some sense "back to the basics/essentials" approach, not just in programming but also in running the code, and even this is enough to be successful. BTW, its syntactic clumsiness and shortcomings (hipsters are blogging about) came from being statically typed, just admit it. On the other side, being C-like and already having C-to-Go translators opens up the road to static-analyzing and other tools. Go is the product of old-school (Bell labs) minds (like Smalltalk or Lisps) not of bunch of punks.)

arthurcolle 11y ago
Joe Armstrong's thesis, for the interested: http://www.erlang.org/download/armstrong_thesis_2003.pdf http://www.erlang.org/download/armstrong_thesis_2003.pdf
biokoda 11y ago
> User-level runtime, which is trying to do kernel's job is a problem, but being mostly-functional it, at least, have no threading/locking problems - so it scales. Nothing much to talk about. Spoken as someone who has never really used it. Dismissing it as nothing much to talk about is ridiculous.
- dschiptsov 11y ago
  Erlang is "great". There is nothing much to talk about.

swagmeister 11y ago

>Finally, JavaScript handles the modern web well, but it isn't perfect. If a request does something that is especially CPU-heavy, every single user of your application will be waiting. One thing you might want to take into account is that ES2015 generators allow you to write long, blocking functions as generators that partially compute the result before deferring further computation to somewhere further along in the message queue. This allows you to spread out blocking computations so that you can still serve requests.

jbverschoor 11y ago

Important to note is that Elixir is created y Jose Valim from plataformatec. An important person and company in the Ruby community

georgeg 11y ago

I feel that this discussion would be incomplete without mentioning D-lang (http://dlang.org http://dlang.org) and the vibed framework (http://vibed.org http://vibed.org) as alternatives to the technology platforms that the author mentioned.

odiroot 11y ago

> Somewhere, however, that has been extrapolated to the idea that Go is a good language for writing web apps. I don't believe that's the case. I have always had this feeling and thought why isn't more people speaking up about that. For me it's a good improvement from C++ (and maybe C as well), somehow well-suited for systems programming. I never understood how people can claim it to be natural "upgrade" from Python or Ruby. I have a feeling the opposite is actually the case. This of course is all in the web-development context, not in general one.

fiatjaf 11y ago

Code samples side-by-side comparison: http://rosetta.alhur.es/compare/go/elixir/# http://rosetta.alhur.es/compare/go/elixir/#

prasoon2211 11y ago

I am utterly baffled by people who use the phrase "The Unix Philosophy" for justifying a piece of software but don't understand that Unix philosophy is in the context of software that can be composed together. That is why the other tenet of the Unix philosophy is to use text streams for all I/O.

vinceguidry 11y ago

Just keep using Ruby or, if you must, Node. Rails 5 is going to fit those use cases just fine. Web programming is entirely too complicated to roll your own stack unless you absolutely need to.