6 ms·

Have you tried python/ Django? I haven't used elixir but I my productivity with Django is much bigger than when compared with other solutions like php, node, j

Have you tried python/ Django? I haven't used elixir but I my productivity with Django is much bigger than when compared with other solutions like php, node, java/spring, c#.net etc. I am talking about good ol' traditional web apps, no fancy spa stuff where I can use Django in all its glory: cbvs, forms, admin, auth and the huge package ecosystem. Give it a try if you haven't, even just the Django tutorial should give you a hint of the productivity enchantment you'll have!

neya 8y ago
Of course, I have used Django (and I still do for data-heavy applications). Python and ruby are quite similar syntactically, but very different philosophically. This is beautifully elaborated on this page here: https://rubyonrails.org/doctrine/ https://rubyonrails.org/doctrine/ and hence my preference for Ruby over Python. Not saying python is bad at all, just that I only have specific use cases I like to use Python for, mostly stuff that needs Pandas.
weberc2 8y ago
One thing that plagues us about async Python in production is the propensity for a single synchronous call to bring down a server. The problem tends to be difficult to debug since it often manifests itself in timeouts for requests that aren't actually issuing the blocking request, but for which can't be serviced because the event loop is blocked nonetheless. It's also easy to add bugs in async code (e.g., forgetting to 'await' and getting back a promise instead of a response object). Of course, we could stick with sync Python, but that has lots of other problems (namely it's difficult to pack Python server processes onto hosts with passable efficiency). Elixir and Go just skirt these problems altogether because all I/O is async under the hood (no need for "await" keywords), and both languages support efficient concurrency and parallelism. One process can fully utilize a host. Of course, this doesn't speak to the quality of available web frameworks, which may or may not matter for your application.
- jashmatthews 8y ago
  Not a Python dev but I worked a lot with Ruby performance a lot for the past few years. Do you really need async IO? Even at Google scale[1] it's kinda a waste of time for web/job servers and only required for proxying etc. The overhead of threads is massively overstated [2] Ruby scales a long way using Puma or Phusion Passenger with one process per core (just like NodeJS) and adding threads until you hit CPU saturation. Python must have something similar? [1] https://www.slideshare.net/e456/tyma-paulmultithreaded1 https://www.slideshare.net/e456/tyma-paulmultithreaded1 [2] https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/ https://eli.thegreenplace.net/2018/measuring-context-switchi...
  - deleted 8y ago
    [deleted]
- optimuspaul 8y ago
  > One thing that plagues us about async Python in production is the propensity for a single synchronous call to bring down a server. Probably need a better framework. I've never had such a problem come up unless I was trying to be clever and not use an established framework.
  - weberc2 8y ago
    You don’t understand the problem you’re criticizing. If you’re using an async web framework like aiohttp and something in the depths of one of your routes does sync IO, it will block your event loop. Nothing clever required. There isn’t a web framework that I’m aware of which magically makes all sync requests async.
    - jashmatthews 8y ago
      > There isn’t a web framework that I’m aware of which magically makes all sync requests async. Waitress gets part of the way there. IIUC Request/response is done via asyncio but the actual web app part uses a thread so you can't accidentally block the whole thing.
      - weberc2 8y ago
        Interesting. I wonder how it manages the threading with the GIL and all that.
        jashmatthews 8y ago
        Thread per request works because the GIL is released during blocking IO. You only need one process per core and each process runs multiple threads. It saves a massive amount of RAM compared to trying to cram 50 (g)unicorns onto a server.
    - optimuspaul 8y ago
      Funny that you insult me and then backup my vague comment with more specifics. My point is that you need to be aware of what is blocking all the way down, all frameworks you are using. It is possible, maybe not magical or trivial, to making everything async. Please don't assume you know what someone understands. Try asking questions when comments seem vague or stupid like mine did.
udfalkso 8y ago
I've written some rather large python apps with Django and Flask. I'd never voluntarily choose it again over Elixir/Phoenix. (Only if there was heavy numerical processing or something of the sort where a library like Pandas would be necessary.) Working with Elixir/Phoenix is a far superior experience in nearly every way for web/api IMO.
iLemming 8y ago
I have used Ruby, Python and Node. Built Angular and React apps using Typescript, Coffeescript, Babel. I haven't tried Elixir, but I tried Clojure. It took me sometime to learn the ways of Clojure but now I feel nothing can make me more productive. I simply cannot even think about going back to writing imperative/OOP code and working with no REPL. Clojure makes sense to me today, but if for some reason it stops making sense I honestly can't think of an alternative.
pmontra 8y ago
I made nearly all of my money with Phoenix and Django in 2018 so I'm probably not biased. For projects that can run on a single machine I'd say that Phoenix is slightly better than Django but Rails is much better than both of them. Metrics: ease of development, developer happiness, ease of debugging, ease of deployment, framework coherence (Django is almost not a framework compared to the other two), the ORM, the underlying language. Phoenix wins on parallel jobs because thanks to Elixir it doesn't need ActiveJobs or Celery. Django doesn't win on anything IMHO, except maybe the ease to create an admin CRUD (but Rails has a gem for that.) To add another tool I used, even Django would win against server side JavaScript. I'm using that only in special cases and for demos, because so many more people knows it than other languages.
- spapas82 8y ago
  Considering yours and the other answers I'll definitely give elixir a go. This isn't very easy when you are fully productive with a different tool (Django in my case) and you have projects with expected deadlines... I'm mostly convinced to take the red pill thought! Can you recommend any good elixir/phoenix learning resources? Now that I mentioned learning resources I think that you should agree that this is a point where Django wins: Its documentation and learning resources!
  - lobo_tuerto 8y ago
    Here is a tutorial that might help you in your first approach to Phoenix (a web framework akin to Rails/Django): https://lobotuerto.com/blog/building-a-json-api-in-elixir-with-phoenix/ https://lobotuerto.com/blog/building-a-json-api-in-elixir-wi...
  - pmontra 8y ago
    I learned Elixir and Phoenix on their web sites. Deep links to the starting points. https://hexdocs.pm/phoenix/overview.html https://hexdocs.pm/phoenix/overview.html https://hexdocs.pm/phoenix/Phoenix.html https://hexdocs.pm/phoenix/Phoenix.html https://elixir-lang.org/getting-started/introduction.html https://elixir-lang.org/getting-started/introduction.html https://elixir-lang.org/docs.html https://elixir-lang.org/docs.html If you buy books, look at https://elixir-lang.org/learning.html https://elixir-lang.org/learning.html You should probably start with Elixir but you can do as I did with Ruby/Rails, start with the framework and learn the language as you need it. If you do, in the case of Elixir you'll probably be puzzled by all the Supervisor and Gen* stuff based on OTP. Hint: GenServers are more or less objects with their own CPU https://hexdocs.pm/elixir/GenServer.html#content https://hexdocs.pm/elixir/GenServer.html#content and Supervisors are kind of a systemd internal to the language.

neya 8y ago

Of course, I have used Django (and I still do for data-heavy applications). Python and ruby are quite similar syntactically, but very different philosophically. This is beautifully elaborated on this page here: https://rubyonrails.org/doctrine/ https://rubyonrails.org/doctrine/ and hence my preference for Ruby over Python. Not saying python is bad at all, just that I only have specific use cases I like to use Python for, mostly stuff that needs Pandas.

weberc2 8y ago

One thing that plagues us about async Python in production is the propensity for a single synchronous call to bring down a server. The problem tends to be difficult to debug since it often manifests itself in timeouts for requests that aren't actually issuing the blocking request, but for which can't be serviced because the event loop is blocked nonetheless. It's also easy to add bugs in async code (e.g., forgetting to 'await' and getting back a promise instead of a response object). Of course, we could stick with sync Python, but that has lots of other problems (namely it's difficult to pack Python server processes onto hosts with passable efficiency). Elixir and Go just skirt these problems altogether because all I/O is async under the hood (no need for "await" keywords), and both languages support efficient concurrency and parallelism. One process can fully utilize a host. Of course, this doesn't speak to the quality of available web frameworks, which may or may not matter for your application.

jashmatthews 8y ago
Not a Python dev but I worked a lot with Ruby performance a lot for the past few years. Do you really need async IO? Even at Google scale[1] it's kinda a waste of time for web/job servers and only required for proxying etc. The overhead of threads is massively overstated [2] Ruby scales a long way using Puma or Phusion Passenger with one process per core (just like NodeJS) and adding threads until you hit CPU saturation. Python must have something similar? [1] https://www.slideshare.net/e456/tyma-paulmultithreaded1 https://www.slideshare.net/e456/tyma-paulmultithreaded1 [2] https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/ https://eli.thegreenplace.net/2018/measuring-context-switchi...
- deleted 8y ago
  [deleted]
optimuspaul 8y ago
> One thing that plagues us about async Python in production is the propensity for a single synchronous call to bring down a server. Probably need a better framework. I've never had such a problem come up unless I was trying to be clever and not use an established framework.
- weberc2 8y ago
  You don’t understand the problem you’re criticizing. If you’re using an async web framework like aiohttp and something in the depths of one of your routes does sync IO, it will block your event loop. Nothing clever required. There isn’t a web framework that I’m aware of which magically makes all sync requests async.
  - jashmatthews 8y ago
    > There isn’t a web framework that I’m aware of which magically makes all sync requests async. Waitress gets part of the way there. IIUC Request/response is done via asyncio but the actual web app part uses a thread so you can't accidentally block the whole thing.
    - weberc2 8y ago
      Interesting. I wonder how it manages the threading with the GIL and all that.
      - jashmatthews 8y ago
        Thread per request works because the GIL is released during blocking IO. You only need one process per core and each process runs multiple threads. It saves a massive amount of RAM compared to trying to cram 50 (g)unicorns onto a server.
  - optimuspaul 8y ago
    Funny that you insult me and then backup my vague comment with more specifics. My point is that you need to be aware of what is blocking all the way down, all frameworks you are using. It is possible, maybe not magical or trivial, to making everything async. Please don't assume you know what someone understands. Try asking questions when comments seem vague or stupid like mine did.

udfalkso 8y ago

I've written some rather large python apps with Django and Flask. I'd never voluntarily choose it again over Elixir/Phoenix. (Only if there was heavy numerical processing or something of the sort where a library like Pandas would be necessary.) Working with Elixir/Phoenix is a far superior experience in nearly every way for web/api IMO.

iLemming 8y ago

I have used Ruby, Python and Node. Built Angular and React apps using Typescript, Coffeescript, Babel. I haven't tried Elixir, but I tried Clojure. It took me sometime to learn the ways of Clojure but now I feel nothing can make me more productive. I simply cannot even think about going back to writing imperative/OOP code and working with no REPL. Clojure makes sense to me today, but if for some reason it stops making sense I honestly can't think of an alternative.

pmontra 8y ago

I made nearly all of my money with Phoenix and Django in 2018 so I'm probably not biased. For projects that can run on a single machine I'd say that Phoenix is slightly better than Django but Rails is much better than both of them. Metrics: ease of development, developer happiness, ease of debugging, ease of deployment, framework coherence (Django is almost not a framework compared to the other two), the ORM, the underlying language. Phoenix wins on parallel jobs because thanks to Elixir it doesn't need ActiveJobs or Celery. Django doesn't win on anything IMHO, except maybe the ease to create an admin CRUD (but Rails has a gem for that.) To add another tool I used, even Django would win against server side JavaScript. I'm using that only in special cases and for demos, because so many more people knows it than other languages.

spapas82 8y ago
Considering yours and the other answers I'll definitely give elixir a go. This isn't very easy when you are fully productive with a different tool (Django in my case) and you have projects with expected deadlines... I'm mostly convinced to take the red pill thought! Can you recommend any good elixir/phoenix learning resources? Now that I mentioned learning resources I think that you should agree that this is a point where Django wins: Its documentation and learning resources!
- lobo_tuerto 8y ago
  Here is a tutorial that might help you in your first approach to Phoenix (a web framework akin to Rails/Django): https://lobotuerto.com/blog/building-a-json-api-in-elixir-with-phoenix/ https://lobotuerto.com/blog/building-a-json-api-in-elixir-wi...
- pmontra 8y ago
  I learned Elixir and Phoenix on their web sites. Deep links to the starting points. https://hexdocs.pm/phoenix/overview.html https://hexdocs.pm/phoenix/overview.html https://hexdocs.pm/phoenix/Phoenix.html https://hexdocs.pm/phoenix/Phoenix.html https://elixir-lang.org/getting-started/introduction.html https://elixir-lang.org/getting-started/introduction.html https://elixir-lang.org/docs.html https://elixir-lang.org/docs.html If you buy books, look at https://elixir-lang.org/learning.html https://elixir-lang.org/learning.html You should probably start with Elixir but you can do as I did with Ruby/Rails, start with the framework and learn the language as you need it. If you do, in the case of Elixir you'll probably be puzzled by all the Supervisor and Gen* stuff based on OTP. Hint: GenServers are more or less objects with their own CPU https://hexdocs.pm/elixir/GenServer.html#content https://hexdocs.pm/elixir/GenServer.html#content and Supervisors are kind of a systemd internal to the language.