9 ms·

As someone who is fairly enthusiastic about Go and has implemented a few livelihood-providing production systems in it I am baffled by the number of people who

As someone who is fairly enthusiastic about Go and has implemented a few livelihood-providing production systems in it I am baffled by the number of people who keep trying to use it for application (and especially web application) development. I mean it does feel like superpower when applied to tasks you'd previously have to use C for. But have you tried any of the modern web development stacks? They are like a zillion times more productive. Hint: PHP is not one of those. I guess some people just can't get by without the iron hand of the compiler :)

spdionis 11y ago
I'd say PHP is definitely one of those. Modern PHP web development is pretty productive and definitely high quality. EDIT after reading the article: I do have to agree that concurrency in PHP is a bit of a pain, but those 3d party tools are pretty easy to use and maintain. > Without significant forethought to several levels of caching; such as in memory caching, op caching ... This is so trivial to setup it's not even worth mentioning. > Sure, PHP has PSR standards etc, but they're fairly new and developers have been slow to adopt them. Everyone I know and every library I use uses those standards. PHP is pretty standardized now, especially compared for example to js. PHP frameworks work well out of the box and contain solutions for most use-cases. Go is nice but when I tried it I really missed something like composer. "go get" and commit your dependencies to the repository? Seriously? That's wrong on so many levels. Meanwhile I think composer is one of the best package managers around.
- onion2k 11y ago
  I do have to agree that concurrency in PHP is a bit of a pain It is, but the overwhelming majority of tasks in a web app don't happen concurrently, so it doesn't matter. When it does matter just use something else.
  - paulddraper 11y ago
    "just use something else" That's what I do! (Actually, I do that from the start of the project, so that adding something as pedestrian as concurrency doesn't involve a complete port to another language.)
  - jerf 11y ago
    "It is, but the overwhelming majority of tasks in a web app don't happen concurrently, so it doesn't matter." But is that cause, or is that effect? The dominant web programming languages for the last 20 years have all been single-threaded, so of course the web stack looks single threaded. Personally, I find there's a ton of things that ought to be concurrent but aren't. I mean, most other network apps need to do things concurrently, why not web? Once you start looking at it this way, the staggering number of hacks employed to pry concurrency out of fundamentally single-threaded languages is astonishing. Go is not the only solution to this, there are many. (Go is one of the more Algol-ish language choices that doesn't involve learning a new paradigm, though, and can make it a relatively easy sell where "Let's all learn Lisp!" or "Let's all learn immutable functional programming!", where "all" may be dozens+ people, may not happen. [1]) But I think in five or ten years, "the overwhelming majority of tasks in a web app don't happen concurrently" is going to sound very 200x-ish. [1]: Incidentally, for those who are still baffled by Go's success, notice how all the alternatives involve trying to teach everyone a brand new paradigm. While that has its advantages, when it comes to language popularity, not requiring that has its advantages too. I'm a polyglot myself, so I get how Haskell is nice and Clojure is nice and how they open your mind to new paradigms etc. etc., no sarcasm, fully mean it, if you only know C-style languages I fully recommend you go fix that soon, but when you're trying to get a team of people on the clock to switch languages for a nicer concurrency story, cutting the requisite training time by 90%+ raises the bar very high for those other languages, in relative terms. (Even moreso than it sounds; not only is training costs less, but the risk of training failure is also that much less. It compounds.) I do not mean this as "advocacy", I mean it as explanation.
    - onion2k 11y ago
      Personally, I find there's a ton of things that ought to be concurrent but aren't. What sort of things? I've been writing web software for ~20 years, and the vast majority of things that I've made boil down to "request comes in > validate input data > transaction to database > check transaction worked > write a response". Concurrency has never really been a problem, or even something I've wanted.
      - 11y ago
- riquito 11y ago
  > I'd say PHP is definitely one of those I still don't like it but the landscape definetely changed, and it keeps getting better. > Meanwhile I think composer is one of the best package managers around. Apart from the fact that it uses gigabytes of ram on real projects. At work we ended up using it outside virtual machines, to later copy back the dependencies.
  - alexbilbie 11y ago
    Are you committing the composer.lock file in your projects? Likewise you should try and use as close to absolute version numbers as possible in your composer.json `requires` sections. I used did a quick test (having run `composer clearcache` each time) on one of my projects: Without composer.lock: Memory usage: 75.96MB (peak: 87.5MB), time: 38.54s With composer.lock: Memory usage: 7.47MB (peak: 8.99MB), time: 28.6s
    - riquito 11y ago
      I do, I also have just absolute version numbers. I'm not the only one with such problems https://github.com/composer/composer/issues/1898 https://github.com/composer/composer/issues/1898
  - thejosh 11y ago
    What's a "real project"? I use composer every day, and have 0 problems when doing a `composer install` on production. I also recommend setting up Toran Proxy, which will allow you to ensure you're not boned when Github goes down.
    - riquito 11y ago
      > What's a "real project"? One of not negligible size. They usually have many dependencies. I can see on our composer.json around ~60 dependencies, and the number will only grow (apart some lucky circumstances). https://github.com/composer/composer/issues/1898 https://github.com/composer/composer/issues/1898 > I also recommend setting up Toran Proxy, which will allow you to ensure you're not boned when Github goes down. Yes, that's a good idea
- aries1980 11y ago
  > Go is nice but when I tried it I really missed something like composer. "go get" and commit your dependencies to the repository? Why is this a pb? Makes your app is more resilient to external outages and no need to git clone all the repos with historical data.
afandian 11y ago
Ditto. I used it for something that I would have written in C (and had prior). A glorious language. Gives safety to places where pointer arithmetic and function pointers adds danger while keeping structs and arrays of primitives. Plus great libraries and memory management. And then I thought "why not use it for something web-like". My experience was dreadful. After coming from Python+Django, it felt like writing Java 1.4 (not a good thing). Especially for returning JSON objects with lots of mixed types. So I switched to Clojure and never looked back (Python would have been an equally valid choice). Go's a great language, but it's being applied in some very odd (and potentially unsuitable) places.
- StavrosK 11y ago
  I had the same experience as you. Django (and RoR, I guess?) blows everything else I've tried out of the water in terms of ecosystem, and Python is a joy to program in. Go is fantastic when I want either a small service or a script that I want to deploy as a single executable and have it be reasonably fast, but I find Python much easier to write in. However, that may be because I'm more familiar with Python. How did you like Clojure? Does the ecosystem it compare well against Django? I tried it once during an on-site interview but was put off by the multi-minute startup times.
  - afandian 11y ago
    It's unfair to compare a framework like Django to a language like Clojure. So, comparing the languages, I tried Clojure because a colleague was using it and to me it feels like the best language I have ever used professionally (comparing to C#, C, Obj-C, Python, Java, JavaScript, Ruby, Go) and I'm very happy using it. Great functional programming features, great libraries, I really like the LISP syntax and the stress I'd been having with Python kind of melted away (things like state in objects and the type system (which kind of doesn't really exist most of the time with Clojure)). In terms of doing web type things, the Liberator and Ring libraries feel a lot like a big chunk of Django's routing and middleware functionality. Selmer does a good job of templating. For most user interface work I'm using React.js (which I also really like) so my Clojure code is only serving up JSON on an HTTP API. But for simple templated HTML, Selmer works well. One question is "Django is an entire framework. How does it compare to lots of little libraries?". I have to say that Django is probably the most well constructed pieces of software I have worked with and it hangs together very well. Clojure with a few libraries is very good, but beating Django is a very high bar to reach for any framework or group of libraries. Startup time is an over-done argument. Once you're running a REPL you don't need to restart it, so development isn't slowed down. Once you're running a server you don't need to restart it, so production isn't slowed down.
kqr 11y ago
> I guess some people just can't get by without the iron hand of the compiler Hey, Haskell and Scala exist!
Kiro 11y ago
> But have you tried any of the modern web development stacks? What stacks are you referring to exactly?
- metachris 11y ago
  Take a look at Django [1], for instance. [1] https://www.djangoproject.com/start/overview/ https://www.djangoproject.com/start/overview/
aws_ls 11y ago
The point is, it is broad. You gained by using it in a traditional case where earlier you would have used C. But I've used it in the web app scenario. Replacing Java (jetty/tomcat servlets with pure Java code) with Golang. My own discovery was it could replace the jetty/tomcat with servlets part seamlessly, just with a bunch of http url handlers. I know it could be possible still more easily in other languages/stacks which are "zillion" times more productive. Now, we all know that nothing comes free. For e.g. C++ templates cause compilation to take more time; have heard people complain about Ruby/ROR (including one on this page); I myself hated the Java configuration of the app servers, even in minimalist use of just a Servlet (the least needed for a web app thing), not to forget the SOAP-Servlets (Axis et al) before JSON ( good common sensical structure IMHO from the XML schemas/dtds (any one remember them?!)) became fashionable. So the bloat/overhead can be in terms of useless jargon (e.g. the latter part of above para) which are too verbose and mean something very simple. Slowness e.g. Ruby/Rails. Or simply memory bloat (Which means more servers for the same amount of app processing capability). So please do understand that there could be reasons other than "just can't get by without the iron hand of the compiler", where people use Go. :-) People who have come to realize they wasted a decade chasing promises whether they were called OOP, EJBs, SOAP, XML, App Server, etc. Only to have been left with mysterious crashes because of "out of memory exceptions" (heck, jetty/tomcat are open source, but does any app developer should be debugging them. No, right? ) So there are also people disillusioned by the promises they fell for earlier. Who now prefer the minimalist approach. And actually very much appreciate when the wise people developing Golang, are hesitant to add a thing like Generics, despite the pressure from many quarters. To summarize, why I use it: Don't try to make it too easy for me, and pinch me at wrong times (when I start to get more users for e.g). Just Give me speed and give me transparency baby. I know how to make it work. Edit: Typos and minor rephrase
- Mick-Jogger 11y ago
  I'd love to hear more about replacing tomcat. Can you lead me to some info material on that topic. In our company we rely heavily on application servers, faster alternatives are always worth checking out.
  - 11y ago
coldtea 11y ago
>Hint: PHP is not one of those. Hint, PHP is 100% one of those. The bad rap is either because of hipsterism or for issues that have been long solved. The rest of its warts are no worse than the kind of BS any language has -- in fact before JS got in fashion the same things was said all the time for it too (for its bizarro coercion rules, only fp arithmetic, bs scope rules etc).
- untog 11y ago
  I agree, but if someone were starting a new project I'm not sure why I'd recommend PHP over any other stack.
  - coldtea 11y ago
    Works, gets constantly better, no JS-like fatigue, fast PHP7 engine, tons of tools, libs and support.
    - untog 11y ago
      Isn't all of that true of, say, Ruby?
      - prplhaz4 11y ago
        It may be, but the above poster also left out one of PHP's strengths - availability. It's already running and ready to go on whatever cheap shared host you've been on for the last 20yrs. Ruby/Rails likely isn't.
      - coldtea 11y ago
        The "fast PHP7 engine" part not. Raw Ruby was slower (but comparable) to raw PHP, so with this new engine which consistently runs real life workloads 2x, PHP7 should be like twice as fast. And PHP still has more vendors, support in all kinds of hosts, even in third world facilities, and more companies offering commercial support. Plus there's stuff in PHP that don't exist with the same level of maturity/adoption/community in Ruby/Rails, e.g. Wordpress. And even a path to static typing, through Hack.
goldbrick 11y ago
Yep. When you're talking about "web development" and your first argument is about "concurrency", your odds of doing it wrong are likely very high. Learn to profile, learn to cache appropriately, learn to set up data pipelines based on access patterns. Many of us who have learned the dangers of threading the hard way consider it a last resort, and just because you have wonderful primitives like goroutines and channels doesn't mean you shouldn't think first. I'm inclined to link to JRuby's first rule of writing concurrent code: https://github.com/jruby/jruby/wiki/Concurrency-in-jruby#concurrency_basics https://github.com/jruby/jruby/wiki/Concurrency-in-jruby#con... Also, it's relative newness combined with the fact that it is on the lower level of things means that basic tasks that have been iterated to precision on other platforms are still very raw around the edges and require quite a bit more boilerplate, which is not at all suited to almost all "web development". I know, I know. "But it's faster!" I'd take a clean, cohesive system that can scale horizontally even if it takes me 5 times the servers of my entire-system locking clusterfuck that makes me guess about data. There is probably an interesting metaphor to be made that is corollary to the adage about the hammer, something about how if you give that man a screwdriver he starts looking for nails to pound with it?
joncalhoun 11y ago
You likely see this because web applications are one of the most common things developers build, and it is easier to learn a language when you start by building something you are familiar with. When I learned Ruby I came from a Java background, and being able to search for things like "java interfaces in ruby" was incredibly helpful. It is a very succinct way of defining what you are trying to do in the new language, and often leads to a useful post explaining how to do what you want to do (even if that means doing it a completely different way in the new language). I suspect this is also why you see frameworks like Revel gaining so much popularity in Go. Developers coming from Rails, etc all want something they are familiar with, and Revel looks familiar. It may not be the best way to build web apps in Go (I don't know), but limiting what you have to learn has its benefits. I personally view this as a positive thing. It makes it easier for developers to learn Go and find out what it is useful for so that when they can benefit from it they realize it.
esaym 11y ago
Don't worry, I once read a similar article about how C++ can be great for scripting (and that was just a few years ago.)

spdionis 11y ago

I'd say PHP is definitely one of those. Modern PHP web development is pretty productive and definitely high quality. EDIT after reading the article: I do have to agree that concurrency in PHP is a bit of a pain, but those 3d party tools are pretty easy to use and maintain. > Without significant forethought to several levels of caching; such as in memory caching, op caching ... This is so trivial to setup it's not even worth mentioning. > Sure, PHP has PSR standards etc, but they're fairly new and developers have been slow to adopt them. Everyone I know and every library I use uses those standards. PHP is pretty standardized now, especially compared for example to js. PHP frameworks work well out of the box and contain solutions for most use-cases. Go is nice but when I tried it I really missed something like composer. "go get" and commit your dependencies to the repository? Seriously? That's wrong on so many levels. Meanwhile I think composer is one of the best package managers around.

onion2k 11y ago
I do have to agree that concurrency in PHP is a bit of a pain It is, but the overwhelming majority of tasks in a web app don't happen concurrently, so it doesn't matter. When it does matter just use something else.
- paulddraper 11y ago
  "just use something else" That's what I do! (Actually, I do that from the start of the project, so that adding something as pedestrian as concurrency doesn't involve a complete port to another language.)
- jerf 11y ago
  "It is, but the overwhelming majority of tasks in a web app don't happen concurrently, so it doesn't matter." But is that cause, or is that effect? The dominant web programming languages for the last 20 years have all been single-threaded, so of course the web stack looks single threaded. Personally, I find there's a ton of things that ought to be concurrent but aren't. I mean, most other network apps need to do things concurrently, why not web? Once you start looking at it this way, the staggering number of hacks employed to pry concurrency out of fundamentally single-threaded languages is astonishing. Go is not the only solution to this, there are many. (Go is one of the more Algol-ish language choices that doesn't involve learning a new paradigm, though, and can make it a relatively easy sell where "Let's all learn Lisp!" or "Let's all learn immutable functional programming!", where "all" may be dozens+ people, may not happen. [1]) But I think in five or ten years, "the overwhelming majority of tasks in a web app don't happen concurrently" is going to sound very 200x-ish. [1]: Incidentally, for those who are still baffled by Go's success, notice how all the alternatives involve trying to teach everyone a brand new paradigm. While that has its advantages, when it comes to language popularity, not requiring that has its advantages too. I'm a polyglot myself, so I get how Haskell is nice and Clojure is nice and how they open your mind to new paradigms etc. etc., no sarcasm, fully mean it, if you only know C-style languages I fully recommend you go fix that soon, but when you're trying to get a team of people on the clock to switch languages for a nicer concurrency story, cutting the requisite training time by 90%+ raises the bar very high for those other languages, in relative terms. (Even moreso than it sounds; not only is training costs less, but the risk of training failure is also that much less. It compounds.) I do not mean this as "advocacy", I mean it as explanation.
  - onion2k 11y ago
    Personally, I find there's a ton of things that ought to be concurrent but aren't. What sort of things? I've been writing web software for ~20 years, and the vast majority of things that I've made boil down to "request comes in > validate input data > transaction to database > check transaction worked > write a response". Concurrency has never really been a problem, or even something I've wanted.
    - 11y ago
riquito 11y ago
> I'd say PHP is definitely one of those I still don't like it but the landscape definetely changed, and it keeps getting better. > Meanwhile I think composer is one of the best package managers around. Apart from the fact that it uses gigabytes of ram on real projects. At work we ended up using it outside virtual machines, to later copy back the dependencies.
- alexbilbie 11y ago
  Are you committing the composer.lock file in your projects? Likewise you should try and use as close to absolute version numbers as possible in your composer.json `requires` sections. I used did a quick test (having run `composer clearcache` each time) on one of my projects: Without composer.lock: Memory usage: 75.96MB (peak: 87.5MB), time: 38.54s With composer.lock: Memory usage: 7.47MB (peak: 8.99MB), time: 28.6s
  - riquito 11y ago
    I do, I also have just absolute version numbers. I'm not the only one with such problems https://github.com/composer/composer/issues/1898 https://github.com/composer/composer/issues/1898
- thejosh 11y ago
  What's a "real project"? I use composer every day, and have 0 problems when doing a `composer install` on production. I also recommend setting up Toran Proxy, which will allow you to ensure you're not boned when Github goes down.
  - riquito 11y ago
    > What's a "real project"? One of not negligible size. They usually have many dependencies. I can see on our composer.json around ~60 dependencies, and the number will only grow (apart some lucky circumstances). https://github.com/composer/composer/issues/1898 https://github.com/composer/composer/issues/1898 > I also recommend setting up Toran Proxy, which will allow you to ensure you're not boned when Github goes down. Yes, that's a good idea
aries1980 11y ago
> Go is nice but when I tried it I really missed something like composer. "go get" and commit your dependencies to the repository? Why is this a pb? Makes your app is more resilient to external outages and no need to git clone all the repos with historical data.

afandian 11y ago

Ditto. I used it for something that I would have written in C (and had prior). A glorious language. Gives safety to places where pointer arithmetic and function pointers adds danger while keeping structs and arrays of primitives. Plus great libraries and memory management. And then I thought "why not use it for something web-like". My experience was dreadful. After coming from Python+Django, it felt like writing Java 1.4 (not a good thing). Especially for returning JSON objects with lots of mixed types. So I switched to Clojure and never looked back (Python would have been an equally valid choice). Go's a great language, but it's being applied in some very odd (and potentially unsuitable) places.

StavrosK 11y ago
I had the same experience as you. Django (and RoR, I guess?) blows everything else I've tried out of the water in terms of ecosystem, and Python is a joy to program in. Go is fantastic when I want either a small service or a script that I want to deploy as a single executable and have it be reasonably fast, but I find Python much easier to write in. However, that may be because I'm more familiar with Python. How did you like Clojure? Does the ecosystem it compare well against Django? I tried it once during an on-site interview but was put off by the multi-minute startup times.
- afandian 11y ago
  It's unfair to compare a framework like Django to a language like Clojure. So, comparing the languages, I tried Clojure because a colleague was using it and to me it feels like the best language I have ever used professionally (comparing to C#, C, Obj-C, Python, Java, JavaScript, Ruby, Go) and I'm very happy using it. Great functional programming features, great libraries, I really like the LISP syntax and the stress I'd been having with Python kind of melted away (things like state in objects and the type system (which kind of doesn't really exist most of the time with Clojure)). In terms of doing web type things, the Liberator and Ring libraries feel a lot like a big chunk of Django's routing and middleware functionality. Selmer does a good job of templating. For most user interface work I'm using React.js (which I also really like) so my Clojure code is only serving up JSON on an HTTP API. But for simple templated HTML, Selmer works well. One question is "Django is an entire framework. How does it compare to lots of little libraries?". I have to say that Django is probably the most well constructed pieces of software I have worked with and it hangs together very well. Clojure with a few libraries is very good, but beating Django is a very high bar to reach for any framework or group of libraries. Startup time is an over-done argument. Once you're running a REPL you don't need to restart it, so development isn't slowed down. Once you're running a server you don't need to restart it, so production isn't slowed down.

kqr 11y ago

> I guess some people just can't get by without the iron hand of the compiler Hey, Haskell and Scala exist!

Kiro 11y ago

> But have you tried any of the modern web development stacks? What stacks are you referring to exactly?

metachris 11y ago
Take a look at Django [1], for instance. [1] https://www.djangoproject.com/start/overview/ https://www.djangoproject.com/start/overview/

aws_ls 11y ago

The point is, it is broad. You gained by using it in a traditional case where earlier you would have used C. But I've used it in the web app scenario. Replacing Java (jetty/tomcat servlets with pure Java code) with Golang. My own discovery was it could replace the jetty/tomcat with servlets part seamlessly, just with a bunch of http url handlers. I know it could be possible still more easily in other languages/stacks which are "zillion" times more productive. Now, we all know that nothing comes free. For e.g. C++ templates cause compilation to take more time; have heard people complain about Ruby/ROR (including one on this page); I myself hated the Java configuration of the app servers, even in minimalist use of just a Servlet (the least needed for a web app thing), not to forget the SOAP-Servlets (Axis et al) before JSON ( good common sensical structure IMHO from the XML schemas/dtds (any one remember them?!)) became fashionable. So the bloat/overhead can be in terms of useless jargon (e.g. the latter part of above para) which are too verbose and mean something very simple. Slowness e.g. Ruby/Rails. Or simply memory bloat (Which means more servers for the same amount of app processing capability). So please do understand that there could be reasons other than "just can't get by without the iron hand of the compiler", where people use Go. :-) People who have come to realize they wasted a decade chasing promises whether they were called OOP, EJBs, SOAP, XML, App Server, etc. Only to have been left with mysterious crashes because of "out of memory exceptions" (heck, jetty/tomcat are open source, but does any app developer should be debugging them. No, right? ) So there are also people disillusioned by the promises they fell for earlier. Who now prefer the minimalist approach. And actually very much appreciate when the wise people developing Golang, are hesitant to add a thing like Generics, despite the pressure from many quarters. To summarize, why I use it: Don't try to make it too easy for me, and pinch me at wrong times (when I start to get more users for e.g). Just Give me speed and give me transparency baby. I know how to make it work. Edit: Typos and minor rephrase

Mick-Jogger 11y ago
I'd love to hear more about replacing tomcat. Can you lead me to some info material on that topic. In our company we rely heavily on application servers, faster alternatives are always worth checking out.
- 11y ago

coldtea 11y ago

>Hint: PHP is not one of those. Hint, PHP is 100% one of those. The bad rap is either because of hipsterism or for issues that have been long solved. The rest of its warts are no worse than the kind of BS any language has -- in fact before JS got in fashion the same things was said all the time for it too (for its bizarro coercion rules, only fp arithmetic, bs scope rules etc).

untog 11y ago
I agree, but if someone were starting a new project I'm not sure why I'd recommend PHP over any other stack.
- coldtea 11y ago
  Works, gets constantly better, no JS-like fatigue, fast PHP7 engine, tons of tools, libs and support.
  - untog 11y ago
    Isn't all of that true of, say, Ruby?
    - prplhaz4 11y ago
      It may be, but the above poster also left out one of PHP's strengths - availability. It's already running and ready to go on whatever cheap shared host you've been on for the last 20yrs. Ruby/Rails likely isn't.
    - coldtea 11y ago
      The "fast PHP7 engine" part not. Raw Ruby was slower (but comparable) to raw PHP, so with this new engine which consistently runs real life workloads 2x, PHP7 should be like twice as fast. And PHP still has more vendors, support in all kinds of hosts, even in third world facilities, and more companies offering commercial support. Plus there's stuff in PHP that don't exist with the same level of maturity/adoption/community in Ruby/Rails, e.g. Wordpress. And even a path to static typing, through Hack.

goldbrick 11y ago

Yep. When you're talking about "web development" and your first argument is about "concurrency", your odds of doing it wrong are likely very high. Learn to profile, learn to cache appropriately, learn to set up data pipelines based on access patterns. Many of us who have learned the dangers of threading the hard way consider it a last resort, and just because you have wonderful primitives like goroutines and channels doesn't mean you shouldn't think first. I'm inclined to link to JRuby's first rule of writing concurrent code: https://github.com/jruby/jruby/wiki/Concurrency-in-jruby#concurrency_basics https://github.com/jruby/jruby/wiki/Concurrency-in-jruby#con... Also, it's relative newness combined with the fact that it is on the lower level of things means that basic tasks that have been iterated to precision on other platforms are still very raw around the edges and require quite a bit more boilerplate, which is not at all suited to almost all "web development". I know, I know. "But it's faster!" I'd take a clean, cohesive system that can scale horizontally even if it takes me 5 times the servers of my entire-system locking clusterfuck that makes me guess about data. There is probably an interesting metaphor to be made that is corollary to the adage about the hammer, something about how if you give that man a screwdriver he starts looking for nails to pound with it?

joncalhoun 11y ago

You likely see this because web applications are one of the most common things developers build, and it is easier to learn a language when you start by building something you are familiar with. When I learned Ruby I came from a Java background, and being able to search for things like "java interfaces in ruby" was incredibly helpful. It is a very succinct way of defining what you are trying to do in the new language, and often leads to a useful post explaining how to do what you want to do (even if that means doing it a completely different way in the new language). I suspect this is also why you see frameworks like Revel gaining so much popularity in Go. Developers coming from Rails, etc all want something they are familiar with, and Revel looks familiar. It may not be the best way to build web apps in Go (I don't know), but limiting what you have to learn has its benefits. I personally view this as a positive thing. It makes it easier for developers to learn Go and find out what it is useful for so that when they can benefit from it they realize it.

esaym 11y ago

Don't worry, I once read a similar article about how C++ can be great for scripting (and that was just a few years ago.)