6 ms·

Too bad the author doesn't show specific examples. I can sympathize with the sentiment. The problem with scaling languages like python and ruby in my experience

by flocial 10y ago

Too bad the author doesn't show specific examples. I can sympathize with the sentiment. The problem with scaling languages like python and ruby in my experience is the number of moving parts and jump in deep knowledge required to scale when your application takes off. One day you're happily writing compact code in your favorite language and suddenly you're rewriting core parts in C/Go/Rust while learning a new language and bolting on a variety of moving parts like redis, memcached, etc. to keep your business from becoming a victim of its own success. A lot of the problems are more or less solved problems with well known workarounds but it's still a pain and probably why there's so much buzz around finding the "next (insert your favorite language/framework)". Erlang generated a lot of buzz several years ago but aside from the recent success of WhatsApp it never quite stuck. I'm curious to know how this author thinks differently.

themartorana 10y ago
Now is a fantastic time for languages. Python and Ruby get you where you need to be fast, and if you get far enough and need to scale, there are a huge number of options, from stalwart holdouts like Java and C# (now on Linux!) to newer languages on rock-solid run times like Clojure and Elixir, to whole new languages like Go and Rust. All these languages have their advantages and followers, but the thing they all have in common is first-class concurrency, which everyone now realizes they need (and old Erlang devs will tell you "duh"). Honestly, while I write Go almost exclusively anymore, I think Elixr is the most exciting. The more I learn about Beam the more magical it becomes in my eyes, considering just how old and stable it is. Phoenix is a game changer in many ways.
- rodmena 10y ago
  Elixir Introduces many new concepts to Erlang. I think it adds to the complexity of language. Erlang is enable to do all with a bit more functional code. Overall I agree that Erlang based frameworks are game changer.
  - flocial 10y ago
    > I think it adds to the complexity of language. How so? What makes Erlang more functional? And how is Erlang simpler for you? A big part of the renaissance in programming languages come from developers leveraging rock solid VMs such as BEAM and JVM. It enables developers to have the expressiveness of dynamic languages and without sacrificing performance or scalability later down the road. In the case of Elixir, many feel that it adds some innovative language features like the pipe ("|>") operator and metaprogramming facilities that ease many of the pain points with Erlang. I'm not an expert in Erlang but there are quite a few notable Erlang developers that enthusiastically support Elixir (including some nice words from Joe Armstrong). I'm not arguing with you but curious about your thoughts. Looking forward to the next installments in your series.
    - rdtsc 10y ago
      > feel that it adds some innovative language features like the pipe ("|>") operator and metaprogramming facilities that ease many of the pain points with Erlang Well both points are valid. Elixir does add some great concepts like the pipe, usable macros and others. But with it comes some complexity -- it is a trade-off. I don't think one is a superset of another. Both will appeal to some people and that's fine. I prefer Erlang, but I hear a lot of people put off by Erlang's syntax, so well maybe Elixir will look better for them. One thing I am impressed about Elixir is the community -- Jose and the team, did a fantastic job building not just the language but making a friendly and welcoming community, that is hard overstate.
      - jellisjapan 10y ago
        Could you speak a little more to the point about how you feel Elixir actually adds to the complexity of Erlang? Was that comment mostly referring to the addition of those new concepts you just mentioned? Or were you referring to something else that the language does under the hood that adds to the general complexity?
- IndianAstronaut 10y ago
  >Python and Ruby get you where you need to be fast, My experience with Go has been that it is almost as easy to get it up and running just as fast as with Python.
  - collyw 10y ago
    Has go got a decent web framework that can match features in Django or Rails. I don't find Python any faster to write than other scripting languages, but I do find Django gives me a ton of productivity.
    - lcarlson 10y ago
      The general consensus in the Go community is that the default http.Handler is sufficient for most things. You can leverage additional middle ware or gorilla toolkit for more complex stuff. Most stuff works nicely with net/http.
- wandering2 10y ago
  >Python and Ruby get you where you need to be fast, and if you get far enough and need to scale, there are a huge number of options, from stalwart holdouts like Java and C# (now on Linux!) to newer languages on rock-solid run times like Clojure and Elixir, to whole new languages like Go and Rust. To be clear, are you suggesting that's reasonable to do a rewrite (or at least for certain parts) from Python/Ruby when you need to scale? Is that going to be reasonably accomplishable in many cases? Honest question. Just wondering what you have in mind.
  - toast0 10y ago
    Rewriting systems in another language can certainly be accomplished. If possible, doing it in bits and pieces will help it actually happen; if you do it as a single big switch, you have to work a lot harder to avoid the second-system effect. In this case, you probably first start by switching your message queuing to Erlang (RabbitMQ), since you had a problem with that anyway; then you can expand outwards from there if it makes sense or makes you happy: job running in Erlang, webservices in Erlang, putting the data in mnesia instead of postgres, etc. You can do the same with any language, of course.
- ceslami 10y ago
  > if you get far enough and need to scale Alright -- I'll bite. Rarely anyone "needs to scale." Plenty of $1B businesses can succeed on a fistful of c4.large's running Ruby on Rails. The same Ruby on Rails that ran their MVP. Scaling via language change isn't the path to victory, unless you picked a language that was poorly suited to your domain to begin with. Too many companies end up following this cargo-cult advice, and spend more time grappling with their tools than innovating. Because "concurrency." Someday. Optimizing your choice of language for anything other than a linear relationship between Real Complexity and Implementation Time is a fool's errand and a fiduciary travesty. In all fairness, Elixir/Phoenix could become as well-learned as Ruby on Rails. We'll end up in a best-of-both-worlds scenario. And at that point, I'll happily eat my words. But in the meantime, solve your "scaling" problems by measuring and optimizing, instead of re-writing your app in the flavor-of-the-week.
  - rdtsc 10y ago
    > Rarely anyone "needs to scale." Agree, and I say it as an Erlang full-time dev. Chances are you don't need 9 9s reliability and super scalability. I've heard and seen cases of companies rewriting stuff unnecessarily due to some incompetent people following latest fads. "Oh I read Python has the GIL so we need to switch to Go. Saw on HN everyone is switching" -- cue years wasted in rewriting and destabilizing a solid usable code base.
  - themartorana 10y ago
    I can't think of a single billion dollar Corp that can run Rails on a few AWS boxes. Time and again companies have rewritten systems from MVP to handle data safer, better, and faster, from Dropbox to Twitch to CloudFlare to Uber to Mail.ru... Then there are plenty of 7 figure companies that have also had scale issues. Game companies come to mind first and foremost but they're hardly the only ones. You want to run your marketing website on Rails? Yeah of course. But billion dollar companies on Rails?
    - ceslami 10y ago
      For the sake of discovering a middle ground between our arguments, let's look at an example of a >$1B company running Rails: Github. Most of Github's stack is Ruby on Rails, with specialized components/sub-systems written in C. This is a common theme amongst companies that use Rails or Python at scale. There's a reason why people keep those languages around. Its the same reason why they tend to be used for MVPs: the tool gets out of your way so you can focus on solving the hard problems of your domain. The longer you can preserve those ergonomics, the better.
- ngrilly 10y ago
  > All these languages have their advantages and followers, but the thing they all have in common is first-class concurrency Among the languages you cited, C# has async/await, Clojure has core.async, Elixir has processes and messages, Go has goroutines and channels, but the other languages (Python, Ruby, Java, Rust) have nothing built-in specifically related to concurrency, do they?
  - mjohn 10y ago
    Python 3 has async coroutines built-in, and there are a number of libraries for Python 2 (e.g. twisted, tornado). Python 2 & 3 also have threading and multiprocessing for concurrency. Java, Rust & Ruby have built-in support for concurrency, but I haven't used those languages that much.
    - ngrilly 10y ago
      Maybe I read "first-class" a bit too literally :-) > Python 3 has async coroutines built-in Yes, the asyncio library was introduced in Python 3.4. > there are a number of libraries for Python 2 (e.g. twisted, tornado) Yes, but they are not part of the language per se. > Python 2 & 3 also have threading and multiprocessing for concurrency. Threading and multiprocessing are really not a good fit when the number of concurrent processes increases, because each thread allocates its own stack, which can be quite expensive in terms of memory. This is the reason why Go (and maybe Erlang too but I'm not sure about the implementation) map "green" threads to OS threads, and implement a resizable stack. Libraries like gevent offer something similar for Python, with some low-level trickery. > Java, Rust & Ruby have built-in support for concurrency In the language and/or the standard library? In Java, there is Quasar and Akka, for example, but they are not part of the language/standard library.
      - steveklabnik 10y ago
        > In the language and/or the standard library? In Rust, we have extremely strong concurrency support in the language/standard library in the form of our type system, which disallows data races at compile time. We only provide 1:1 threading, but libraries can use this type system to extend it: there's N:M threading libraries, as well as more exotic concurrency stuff than we provide directly. Rust also generally takes a "no batteries included" approach, generally speaking. In Ruby, there's Thread and Fiber. MRI's GIL hurts it here, but other implementations don't have this problem.
dwc 10y ago
> Erlang generated a lot of buzz several years ago but aside from the recent success of WhatsApp it never quite stuck. Erlang is quietly running a lot of stuff out there. It's almost certainly running some bits of infrastructure that you use daily, or in a supporting role for it. People who are not old Erlang hackers are picking it for new projects. Erlang hasn't been and probably will never be quite mainstream, but to say it "hasn't stuck" might be missing the point: it's a mature and performant language that has some very nice standard features in OTP that are lacking or less mature in other languages. If your problem domain is smack in the middle of Erlang's strong points then it's worth considering. It's not going away any time soon.
- flocial 10y ago
  I see your point and yes I know that Erlang has decades of production use and shines in lots of infrastructure applications, game servers, etc. I was mainly referring to the buzz generated quite a few years ago when the first Pragmatic Programmer books on Erlang came out. There were a lot of startups testing the waters with Erlang but I just got the impression that the language didn't quite take off despite the merits touted about Erlang's strength as a functional language and the built-in handling of concurrency. This is all of course compared to the current buzz surrounding Elixir/Phoenix. I didn't intend to dismiss Erlang's amazing track record and applications to the domains where it continues to shine. This is roughly the time span I was referring to when I said "buzz": https://hn.algolia.com/?query=erlang&sort=byPopularity&prefix&page=0&dateRange=custom&type=story&dateStart=1104537600&dateEnd=1262390400 https://hn.algolia.com/?query=erlang&sort=byPopularity&prefi...

by flocial 10y ago

themartorana 10y ago

Now is a fantastic time for languages. Python and Ruby get you where you need to be fast, and if you get far enough and need to scale, there are a huge number of options, from stalwart holdouts like Java and C# (now on Linux!) to newer languages on rock-solid run times like Clojure and Elixir, to whole new languages like Go and Rust. All these languages have their advantages and followers, but the thing they all have in common is first-class concurrency, which everyone now realizes they need (and old Erlang devs will tell you "duh"). Honestly, while I write Go almost exclusively anymore, I think Elixr is the most exciting. The more I learn about Beam the more magical it becomes in my eyes, considering just how old and stable it is. Phoenix is a game changer in many ways.

rodmena 10y ago
Elixir Introduces many new concepts to Erlang. I think it adds to the complexity of language. Erlang is enable to do all with a bit more functional code. Overall I agree that Erlang based frameworks are game changer.
- flocial 10y ago
  > I think it adds to the complexity of language. How so? What makes Erlang more functional? And how is Erlang simpler for you? A big part of the renaissance in programming languages come from developers leveraging rock solid VMs such as BEAM and JVM. It enables developers to have the expressiveness of dynamic languages and without sacrificing performance or scalability later down the road. In the case of Elixir, many feel that it adds some innovative language features like the pipe ("|>") operator and metaprogramming facilities that ease many of the pain points with Erlang. I'm not an expert in Erlang but there are quite a few notable Erlang developers that enthusiastically support Elixir (including some nice words from Joe Armstrong). I'm not arguing with you but curious about your thoughts. Looking forward to the next installments in your series.
  - rdtsc 10y ago
    > feel that it adds some innovative language features like the pipe ("|>") operator and metaprogramming facilities that ease many of the pain points with Erlang Well both points are valid. Elixir does add some great concepts like the pipe, usable macros and others. But with it comes some complexity -- it is a trade-off. I don't think one is a superset of another. Both will appeal to some people and that's fine. I prefer Erlang, but I hear a lot of people put off by Erlang's syntax, so well maybe Elixir will look better for them. One thing I am impressed about Elixir is the community -- Jose and the team, did a fantastic job building not just the language but making a friendly and welcoming community, that is hard overstate.
    - jellisjapan 10y ago
      Could you speak a little more to the point about how you feel Elixir actually adds to the complexity of Erlang? Was that comment mostly referring to the addition of those new concepts you just mentioned? Or were you referring to something else that the language does under the hood that adds to the general complexity?
IndianAstronaut 10y ago
>Python and Ruby get you where you need to be fast, My experience with Go has been that it is almost as easy to get it up and running just as fast as with Python.
- collyw 10y ago
  Has go got a decent web framework that can match features in Django or Rails. I don't find Python any faster to write than other scripting languages, but I do find Django gives me a ton of productivity.
  - lcarlson 10y ago
    The general consensus in the Go community is that the default http.Handler is sufficient for most things. You can leverage additional middle ware or gorilla toolkit for more complex stuff. Most stuff works nicely with net/http.
wandering2 10y ago
>Python and Ruby get you where you need to be fast, and if you get far enough and need to scale, there are a huge number of options, from stalwart holdouts like Java and C# (now on Linux!) to newer languages on rock-solid run times like Clojure and Elixir, to whole new languages like Go and Rust. To be clear, are you suggesting that's reasonable to do a rewrite (or at least for certain parts) from Python/Ruby when you need to scale? Is that going to be reasonably accomplishable in many cases? Honest question. Just wondering what you have in mind.
- toast0 10y ago
  Rewriting systems in another language can certainly be accomplished. If possible, doing it in bits and pieces will help it actually happen; if you do it as a single big switch, you have to work a lot harder to avoid the second-system effect. In this case, you probably first start by switching your message queuing to Erlang (RabbitMQ), since you had a problem with that anyway; then you can expand outwards from there if it makes sense or makes you happy: job running in Erlang, webservices in Erlang, putting the data in mnesia instead of postgres, etc. You can do the same with any language, of course.
ceslami 10y ago
> if you get far enough and need to scale Alright -- I'll bite. Rarely anyone "needs to scale." Plenty of $1B businesses can succeed on a fistful of c4.large's running Ruby on Rails. The same Ruby on Rails that ran their MVP. Scaling via language change isn't the path to victory, unless you picked a language that was poorly suited to your domain to begin with. Too many companies end up following this cargo-cult advice, and spend more time grappling with their tools than innovating. Because "concurrency." Someday. Optimizing your choice of language for anything other than a linear relationship between Real Complexity and Implementation Time is a fool's errand and a fiduciary travesty. In all fairness, Elixir/Phoenix could become as well-learned as Ruby on Rails. We'll end up in a best-of-both-worlds scenario. And at that point, I'll happily eat my words. But in the meantime, solve your "scaling" problems by measuring and optimizing, instead of re-writing your app in the flavor-of-the-week.
- rdtsc 10y ago
  > Rarely anyone "needs to scale." Agree, and I say it as an Erlang full-time dev. Chances are you don't need 9 9s reliability and super scalability. I've heard and seen cases of companies rewriting stuff unnecessarily due to some incompetent people following latest fads. "Oh I read Python has the GIL so we need to switch to Go. Saw on HN everyone is switching" -- cue years wasted in rewriting and destabilizing a solid usable code base.
- themartorana 10y ago
  I can't think of a single billion dollar Corp that can run Rails on a few AWS boxes. Time and again companies have rewritten systems from MVP to handle data safer, better, and faster, from Dropbox to Twitch to CloudFlare to Uber to Mail.ru... Then there are plenty of 7 figure companies that have also had scale issues. Game companies come to mind first and foremost but they're hardly the only ones. You want to run your marketing website on Rails? Yeah of course. But billion dollar companies on Rails?
  - ceslami 10y ago
    For the sake of discovering a middle ground between our arguments, let's look at an example of a >$1B company running Rails: Github. Most of Github's stack is Ruby on Rails, with specialized components/sub-systems written in C. This is a common theme amongst companies that use Rails or Python at scale. There's a reason why people keep those languages around. Its the same reason why they tend to be used for MVPs: the tool gets out of your way so you can focus on solving the hard problems of your domain. The longer you can preserve those ergonomics, the better.
ngrilly 10y ago
> All these languages have their advantages and followers, but the thing they all have in common is first-class concurrency Among the languages you cited, C# has async/await, Clojure has core.async, Elixir has processes and messages, Go has goroutines and channels, but the other languages (Python, Ruby, Java, Rust) have nothing built-in specifically related to concurrency, do they?
- mjohn 10y ago
  Python 3 has async coroutines built-in, and there are a number of libraries for Python 2 (e.g. twisted, tornado). Python 2 & 3 also have threading and multiprocessing for concurrency. Java, Rust & Ruby have built-in support for concurrency, but I haven't used those languages that much.
  - ngrilly 10y ago
    Maybe I read "first-class" a bit too literally :-) > Python 3 has async coroutines built-in Yes, the asyncio library was introduced in Python 3.4. > there are a number of libraries for Python 2 (e.g. twisted, tornado) Yes, but they are not part of the language per se. > Python 2 & 3 also have threading and multiprocessing for concurrency. Threading and multiprocessing are really not a good fit when the number of concurrent processes increases, because each thread allocates its own stack, which can be quite expensive in terms of memory. This is the reason why Go (and maybe Erlang too but I'm not sure about the implementation) map "green" threads to OS threads, and implement a resizable stack. Libraries like gevent offer something similar for Python, with some low-level trickery. > Java, Rust & Ruby have built-in support for concurrency In the language and/or the standard library? In Java, there is Quasar and Akka, for example, but they are not part of the language/standard library.
    - steveklabnik 10y ago
      > In the language and/or the standard library? In Rust, we have extremely strong concurrency support in the language/standard library in the form of our type system, which disallows data races at compile time. We only provide 1:1 threading, but libraries can use this type system to extend it: there's N:M threading libraries, as well as more exotic concurrency stuff than we provide directly. Rust also generally takes a "no batteries included" approach, generally speaking. In Ruby, there's Thread and Fiber. MRI's GIL hurts it here, but other implementations don't have this problem.

dwc 10y ago

> Erlang generated a lot of buzz several years ago but aside from the recent success of WhatsApp it never quite stuck. Erlang is quietly running a lot of stuff out there. It's almost certainly running some bits of infrastructure that you use daily, or in a supporting role for it. People who are not old Erlang hackers are picking it for new projects. Erlang hasn't been and probably will never be quite mainstream, but to say it "hasn't stuck" might be missing the point: it's a mature and performant language that has some very nice standard features in OTP that are lacking or less mature in other languages. If your problem domain is smack in the middle of Erlang's strong points then it's worth considering. It's not going away any time soon.

flocial 10y ago
I see your point and yes I know that Erlang has decades of production use and shines in lots of infrastructure applications, game servers, etc. I was mainly referring to the buzz generated quite a few years ago when the first Pragmatic Programmer books on Erlang came out. There were a lot of startups testing the waters with Erlang but I just got the impression that the language didn't quite take off despite the merits touted about Erlang's strength as a functional language and the built-in handling of concurrency. This is all of course compared to the current buzz surrounding Elixir/Phoenix. I didn't intend to dismiss Erlang's amazing track record and applications to the domains where it continues to shine. This is roughly the time span I was referring to when I said "buzz": https://hn.algolia.com/?query=erlang&sort=byPopularity&prefix&page=0&dateRange=custom&type=story&dateStart=1104537600&dateEnd=1262390400 https://hn.algolia.com/?query=erlang&sort=byPopularity&prefi...