4 ms·

I've written about this [1], but in brief, my opinion is that selecting a high-performance platform is extremely reasonable, all else being equal (equal familia

by bhauer 10y ago

I've written about this [1], but in brief, my opinion is that selecting a high-performance platform is extremely reasonable, all else being equal (equal familiarity with Go and Ruby, for example). Opting for a high-performance platform allows you the freedom to build your application code in a genuinely low-friction deferred-optimization manner. Put another way, a high-performance platform provides a very high ceiling, allowing your application to be more brute-force with its implementation. You don't have to be sub-consciously worrying about performance gotchas while implementing your code because a high-performance platform gives you freedom to be inefficient within your application domain. Not only that, a high-performance platform postpones your first scale event, and in some cases indefinitely defers it. I've found that applications on high-performance platforms tend to be easier to deal with on a day-to-day basis because they do not collect the various deployment performance-oriented cruft that you typically see with low-performance systems. High-performance platforms have simpler system architecture (fewer external processes, less monitoring overhead, etc.) A bonus is that the user experience will be just that much better thanks to low-latency responses. [1] https://www.techempower.com/blog/2016/02/10/think-about-performance-before-building-a-web-application/ https://www.techempower.com/blog/2016/02/10/think-about-perf...

nullnilvoid 10y ago
The same argument can be made about C/C++, Java and Rust. These languages are even more performant than Go in general. Why not choose them? Why Go?
- rjammala 10y ago
  Because Go is a fast, fun and productive language. It is important to have all the three :-)
- jerf 10y ago
  For C/C++, don't use a memory-unsafe language to speak to networks. (The fact that so many things already do is no excuse and adequate demonstration of why. Also arguably more true of C than C++ but I'm not particularly impressed with claims that C++ is safe if you just "do it right" because that's the sort of gap you can drive a truck through.) Rust is still a bit shy of web libraries, and may be overkill for some use cases, but otherwise, go for it. Go for it with Java too. However, the performance gap between Go and Rust is much smaller than the gap between Go and a dynamically-typed language, even one JIT'ed to the n'th degree, and the gap between Go and Java generally lost in the noise [1]. Between Go, Java, and Rust, you've probably got a good case that you'll get to more-or-less production-ready code fastest in Go. (And yes, "more-or-less" is a gap big enough to drive a truck through too. I preemptively pretty much agree with everything anybody might care to write about that issue in reply. :) ) [1]: I suppose I should point out that a perf gap of 2 or 3 is "generally lost in the noise". In the real world what tends to control which such language has the better implementation of something for most tasks is who has taken more time to write an optimized version. It's when you start getting up to the 10x-25x range that the gap between Go and a dynamic language can be that it's not really "lost in the noise" anymore; in that case, the faster language can end up simply faster than the slow language even if the slow language is given a lot of extra love (assuming no "change to a different language" shenanigans).
- bhauer 10y ago
  To be clear, I am not suggesting Go specifically, although it is certainly a very good choice and the article this thread is linked to makes its own good arguments in favor of Go. Java 8 also has some very high-productivity modern web application frameworks, as do several other high-performance platforms. I generally advise selecting anything within the top third—what I loosely call the high-performance tier—of our benchmarks project. There are a bunch of options there, Go included. Making a platform selection that is informed, in part, on the language/platform's performance is a reasonable thing to do. As long as you can be equally productive (or even if you are a little less productive) with a high-performance platform, you will likely endure less pain during the initial several months once your system goes live and considerably less pain over the long haul. Plus, it's really great to have a wicked-fast web app with very little performance-tuning effort.
oliwarner 10y ago
Development performance is arguably more important. Developers are way more expensive than servers. You shrug off the established players but all else is very much not equal. Until Go has its own mature Django or WordPress projects, you're spending a lot more time reimplementing the wheel.
- bhauer 10y ago
  YMMV. In my experience, developers are equally productive (and in many cases, more productive) on high-performance platforms for a variety of reasons. These include the aforementioned reduced friction of avoiding subconscious performance debt, the increased productivity of a typing system (many high-performance platforms have stronger typing systems), and the reduced mental burden of a simplified system architecture. Yes, some platforms (e.g., WordPress) give you certain functionality off the shelf, but if your application isn't a CMS or blog, then the utility of that functionality is low. When building a custom REST or REST-like server for an application, a CMS platform isn't necessarily a reasonable starting point. As with anything in technology, many variables need to be evaluated to make a decision. My point here is that performance is a consideration—more significant and valuable than many people understand—and it at least somewhat objective. Developer productivity is more difficult to objectively measure and varies by team on matters such as previous experience.
- marcus_holmes 10y ago
  One of the main beautiful things about Golang is that the community prefers libraries to frameworks. There may well be a MVC framework developed in/for Golang, but it probably won't be used that much by Golang devs. A framework gets you going real quick, but at some point, probably 3-6 months in, you'll need to do something that the framework doesn't like. At that point the framework suddenly becomes a hindrance rather than a help. You spend more and more time fighting the framework and writing more and more code that lives outside the framework. After a few years you've wasted way more time than you ever gained from using the framework. Libraries are built to provide capabilities to your code. Until you've experienced a good standard library (like Golang's) then this makes no sense. It's common for newbies to Golang (like I did) to try and create supersets of the libraries and create their own framework. But every new project comes back to the simplicity and ease of using the standard library. I like the OP's approach of having repos full of useful middleware and handlers. This makes much, much more sense for Golang development than a Django clone. Try it, you'll like it.
deleted 10y ago
[deleted]

by bhauer 10y ago

nullnilvoid 10y ago

The same argument can be made about C/C++, Java and Rust. These languages are even more performant than Go in general. Why not choose them? Why Go?

rjammala 10y ago
Because Go is a fast, fun and productive language. It is important to have all the three :-)
jerf 10y ago
For C/C++, don't use a memory-unsafe language to speak to networks. (The fact that so many things already do is no excuse and adequate demonstration of why. Also arguably more true of C than C++ but I'm not particularly impressed with claims that C++ is safe if you just "do it right" because that's the sort of gap you can drive a truck through.) Rust is still a bit shy of web libraries, and may be overkill for some use cases, but otherwise, go for it. Go for it with Java too. However, the performance gap between Go and Rust is much smaller than the gap between Go and a dynamically-typed language, even one JIT'ed to the n'th degree, and the gap between Go and Java generally lost in the noise [1]. Between Go, Java, and Rust, you've probably got a good case that you'll get to more-or-less production-ready code fastest in Go. (And yes, "more-or-less" is a gap big enough to drive a truck through too. I preemptively pretty much agree with everything anybody might care to write about that issue in reply. :) ) [1]: I suppose I should point out that a perf gap of 2 or 3 is "generally lost in the noise". In the real world what tends to control which such language has the better implementation of something for most tasks is who has taken more time to write an optimized version. It's when you start getting up to the 10x-25x range that the gap between Go and a dynamic language can be that it's not really "lost in the noise" anymore; in that case, the faster language can end up simply faster than the slow language even if the slow language is given a lot of extra love (assuming no "change to a different language" shenanigans).
bhauer 10y ago
To be clear, I am not suggesting Go specifically, although it is certainly a very good choice and the article this thread is linked to makes its own good arguments in favor of Go. Java 8 also has some very high-productivity modern web application frameworks, as do several other high-performance platforms. I generally advise selecting anything within the top third—what I loosely call the high-performance tier—of our benchmarks project. There are a bunch of options there, Go included. Making a platform selection that is informed, in part, on the language/platform's performance is a reasonable thing to do. As long as you can be equally productive (or even if you are a little less productive) with a high-performance platform, you will likely endure less pain during the initial several months once your system goes live and considerably less pain over the long haul. Plus, it's really great to have a wicked-fast web app with very little performance-tuning effort.

oliwarner 10y ago

Development performance is arguably more important. Developers are way more expensive than servers. You shrug off the established players but all else is very much not equal. Until Go has its own mature Django or WordPress projects, you're spending a lot more time reimplementing the wheel.

bhauer 10y ago
YMMV. In my experience, developers are equally productive (and in many cases, more productive) on high-performance platforms for a variety of reasons. These include the aforementioned reduced friction of avoiding subconscious performance debt, the increased productivity of a typing system (many high-performance platforms have stronger typing systems), and the reduced mental burden of a simplified system architecture. Yes, some platforms (e.g., WordPress) give you certain functionality off the shelf, but if your application isn't a CMS or blog, then the utility of that functionality is low. When building a custom REST or REST-like server for an application, a CMS platform isn't necessarily a reasonable starting point. As with anything in technology, many variables need to be evaluated to make a decision. My point here is that performance is a consideration—more significant and valuable than many people understand—and it at least somewhat objective. Developer productivity is more difficult to objectively measure and varies by team on matters such as previous experience.
marcus_holmes 10y ago
One of the main beautiful things about Golang is that the community prefers libraries to frameworks. There may well be a MVC framework developed in/for Golang, but it probably won't be used that much by Golang devs. A framework gets you going real quick, but at some point, probably 3-6 months in, you'll need to do something that the framework doesn't like. At that point the framework suddenly becomes a hindrance rather than a help. You spend more and more time fighting the framework and writing more and more code that lives outside the framework. After a few years you've wasted way more time than you ever gained from using the framework. Libraries are built to provide capabilities to your code. Until you've experienced a good standard library (like Golang's) then this makes no sense. It's common for newbies to Golang (like I did) to try and create supersets of the libraries and create their own framework. But every new project comes back to the simplicity and ease of using the standard library. I like the OP's approach of having repos full of useful middleware and handlers. This makes much, much more sense for Golang development than a Django clone. Try it, you'll like it.

deleted 10y ago

[deleted]