11 ms·

>Compared with Ruby, PHP, Python, or Javascript, you're going to get great memory and latency performance, and libraries that do what you expect. Isn't picking

by atarian 10y ago

>Compared with Ruby, PHP, Python, or Javascript, you're going to get great memory and latency performance, and libraries that do what you expect. Isn't picking a language to solve memory/latency issues a pre-optimization? Also I'm not sure if one can argue that libraries from one particular language are better at doing what you expect than libraries from another language. Disclaimer: I'm trying to understand how much of what people are saying about Go is hype. People are telling me things like you can cross-compile on different platforms and output a binary, but I fail to see how these things are important for most API's and web apps.

ksubedi 10y ago
Probably an unpopular opinion but I don't think pre-optimization is a bad thing specially in use cases where you will need to optimize the application later, as refactoring things for optimization later is much more time consuming. That being said, it all depends on the use case. And about your point on binary output, its not just about being able to get one binary and running it in different platforms, its also about being able to run it without much setup in the future. For example, I had a hard time getting a nodejs app that I built a few years ago running again since so many libraries were deprecated and I had a lot of broken packages, but if it was built using Go, it would just be one binary with all the dependencies packaged in and I would be able to run it without any issues.
- jwilliams 10y ago
  I think people have come to interpret the pre-optimization mantra in different ways, which leads to some confusion. Personally I think it's fine to have optimization goals, particularly around things like performance, cost and security (or even your ability to hire engineers). Maybe you park some of them while you prove another point, but you can (and should) measure and adapt along the way.
- z3t4 10y ago
  this is why i only use pure JS in nodejs. then it will always work for that version of nodejs. you cant asume that binary version of nodejs will work forever though.
- conceptme 10y ago
  Does GO have a dependency manager yet? last time i checked it out it was only things like go get which did a git checkout? I doubt anything would keep working on active libraries without version locking composer / yarn seem to do this a lot better.
  - ksubedi 10y ago
    I am not sure about the situation of dependency management on Go atm (havent used it for a few months), but in my case if I had a pre-compiled binary, I could just fire it up without having to worry about compiling from source. I was not a big fan of the way Go handled dependency a while ago, but I am sure there are better tools out there now.
  - Zikes 10y ago
    dep is being adopted as the officially "blessed" tool of choice.
    - jgimenez 10y ago
      Yes, not really an official solution yet, but they're getting there.
      - fancy_pantser 10y ago
        It will be in 1.10. Details and roadmap: https://github.com/golang/dep/wiki/Roadmap https://github.com/golang/dep/wiki/Roadmap
kevinburke 10y ago
There are a lot of studies correlating response time with e.g. the percentage of users that complete an online checkout.
felipellrocha 10y ago
I'd say that it's a pre-optimization if you're debating between python and c++. Namely, expressiveness vs performance. In the case of go, a lot of people feel like it gives you about the same amount of expressiveness, while also giving a shit ton of performance. So, in this case, I wouldn't say it's a pre-optimization. It's just being smart about the tool you select to solve the problem at hand.
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).
skrebbel 10y ago
> Isn't picking a language to solve memory/latency issues a pre-optimization? Yes it is, but if there are no perceived downsides then it's no biggie. I.e. Go is well supported by tooling, it has a good and growing open source ecosystem, it appears to support a level of day-to-day developer productivity comparable to other high-level languages, and so on. In other words, the hidden corollary to the standard "premature optimization" meme is that optimization always has negative side effects (such as complex or difficult to maintain code). But sometimes, these negative side effects can be negligible and choosing a particular language over another is often one of those times.
searchhn 10y ago
Not really.. Picking the right language in my opinion is very vital based on your use case. Especially if memory / latency and throughput are very important for what you are building. For my project after a month in golang, I had to switch to C to avoid the GC pause. It also gave me total control over memory and made best use of CPU. Will I choose C for every project ?, definitely not but based on what you are building, it is good to make that choice early on in the project.
c2h5oh 10y ago
TL;DR; Go promisses interpreted language developer productivity with C-like performance of the code and it delivers. Longer version: - I've been writing almost exclusively Go code as my full time job for the last 2.5 years - I've coded in Python and PHP full time before - each at least as long as Go (and neither of them was my first or second programming language) - I was able to pick up Go significantly faster than either of the two (0 to push to production in less than 2 weeks) - I'm at least as productive (measured in problems solved / features delivered in unit of time) in Go as I was in Python - standard library is great and very often replaces the need for 3rd party libraries (performant, production ready HTTP server for example) and makes dependencies "flatter" - deployment of a single static binary vs virtualenv hell (pre-docker) is bliss - it's actually very fast for free - you'll start worrying about (and start spending time on) performance way later Negatives: - dependency management is bad From web app/api perspective: - just using http server from standard library gives you concurency go is known for - each request is a goroutine which is cheap: minimal overhead - you can delay worring about performance (at least from the app part - not db obviously) more. It's easier to throw hardware at the problem when you need 1/10 of the hardware - deployment is easy - single static binary that just works - multiple CPU cores are simply used: you don't have to run multiple processes (node) - http server in standard library is production ready: no need to stick it behind something else - you get all that without sacrificing productivity
- Mikushi 10y ago
  I've had a bit of exposure to it (writing some HTTPS audit tool using Go\Crypto & some third party library - from CloudFlare) and I agree mostly, what struck me as a guy with 10+ years of PHP background is the speed at which I got the first versions of my tool out, really impressive. Definitely keen to may be transition to it if I can find stuff to do to better my knowledge of it. Have you found a decent way to deal with the dependency management, I found it a bit clunky...
  - c2h5oh 10y ago
    Govendor + vendored dependencies in repo
waterside81 10y ago
Shipping self-hosted APIs is painless with Go thanks to how easy it is to cross-compile. Especially if your customers are enterprise and run Windows internally. Previously, we had to ship virtual appliances to our customers which then involved debugging their wacky network setups, their wacky version of VMWare etc. etc. Now it's just one liner build, upload to s3, send out a link, done.
manigandham 10y ago
You mean premature-optimization? That depends on the outcome. Would you call using C++ for developing a videogame as premature? Or just picking the right platform up front to meet the goals? Performance, especially efficiency, is way too often overlooked these days, and provides incredible benefits both for your own development, operations and end user experiences.
psiclops 10y ago
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%" I'd say picking a platform is not, as it is definitely a critical part of your program, especially if it does not greatly increase the complexity of your code.
devsquid 10y ago
Theres lots of reasons to use Go. Mine is the language is really stupid simple. Theres nothing fancy in the syntax, you can pick up a project you put down months ago and easily start working on it again

by atarian 10y ago

ksubedi 10y ago

Probably an unpopular opinion but I don't think pre-optimization is a bad thing specially in use cases where you will need to optimize the application later, as refactoring things for optimization later is much more time consuming. That being said, it all depends on the use case. And about your point on binary output, its not just about being able to get one binary and running it in different platforms, its also about being able to run it without much setup in the future. For example, I had a hard time getting a nodejs app that I built a few years ago running again since so many libraries were deprecated and I had a lot of broken packages, but if it was built using Go, it would just be one binary with all the dependencies packaged in and I would be able to run it without any issues.

jwilliams 10y ago
I think people have come to interpret the pre-optimization mantra in different ways, which leads to some confusion. Personally I think it's fine to have optimization goals, particularly around things like performance, cost and security (or even your ability to hire engineers). Maybe you park some of them while you prove another point, but you can (and should) measure and adapt along the way.
z3t4 10y ago
this is why i only use pure JS in nodejs. then it will always work for that version of nodejs. you cant asume that binary version of nodejs will work forever though.
conceptme 10y ago
Does GO have a dependency manager yet? last time i checked it out it was only things like go get which did a git checkout? I doubt anything would keep working on active libraries without version locking composer / yarn seem to do this a lot better.
- ksubedi 10y ago
  I am not sure about the situation of dependency management on Go atm (havent used it for a few months), but in my case if I had a pre-compiled binary, I could just fire it up without having to worry about compiling from source. I was not a big fan of the way Go handled dependency a while ago, but I am sure there are better tools out there now.
- Zikes 10y ago
  dep is being adopted as the officially "blessed" tool of choice.
  - jgimenez 10y ago
    Yes, not really an official solution yet, but they're getting there.
    - fancy_pantser 10y ago
      It will be in 1.10. Details and roadmap: https://github.com/golang/dep/wiki/Roadmap https://github.com/golang/dep/wiki/Roadmap

kevinburke 10y ago

There are a lot of studies correlating response time with e.g. the percentage of users that complete an online checkout.

felipellrocha 10y ago

I'd say that it's a pre-optimization if you're debating between python and c++. Namely, expressiveness vs performance. In the case of go, a lot of people feel like it gives you about the same amount of expressiveness, while also giving a shit ton of performance. So, in this case, I wouldn't say it's a pre-optimization. It's just being smart about the tool you select to solve the problem at hand.

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).

skrebbel 10y ago

> Isn't picking a language to solve memory/latency issues a pre-optimization? Yes it is, but if there are no perceived downsides then it's no biggie. I.e. Go is well supported by tooling, it has a good and growing open source ecosystem, it appears to support a level of day-to-day developer productivity comparable to other high-level languages, and so on. In other words, the hidden corollary to the standard "premature optimization" meme is that optimization always has negative side effects (such as complex or difficult to maintain code). But sometimes, these negative side effects can be negligible and choosing a particular language over another is often one of those times.

searchhn 10y ago

Not really.. Picking the right language in my opinion is very vital based on your use case. Especially if memory / latency and throughput are very important for what you are building. For my project after a month in golang, I had to switch to C to avoid the GC pause. It also gave me total control over memory and made best use of CPU. Will I choose C for every project ?, definitely not but based on what you are building, it is good to make that choice early on in the project.

c2h5oh 10y ago

TL;DR; Go promisses interpreted language developer productivity with C-like performance of the code and it delivers. Longer version: - I've been writing almost exclusively Go code as my full time job for the last 2.5 years - I've coded in Python and PHP full time before - each at least as long as Go (and neither of them was my first or second programming language) - I was able to pick up Go significantly faster than either of the two (0 to push to production in less than 2 weeks) - I'm at least as productive (measured in problems solved / features delivered in unit of time) in Go as I was in Python - standard library is great and very often replaces the need for 3rd party libraries (performant, production ready HTTP server for example) and makes dependencies "flatter" - deployment of a single static binary vs virtualenv hell (pre-docker) is bliss - it's actually very fast for free - you'll start worrying about (and start spending time on) performance way later Negatives: - dependency management is bad From web app/api perspective: - just using http server from standard library gives you concurency go is known for - each request is a goroutine which is cheap: minimal overhead - you can delay worring about performance (at least from the app part - not db obviously) more. It's easier to throw hardware at the problem when you need 1/10 of the hardware - deployment is easy - single static binary that just works - multiple CPU cores are simply used: you don't have to run multiple processes (node) - http server in standard library is production ready: no need to stick it behind something else - you get all that without sacrificing productivity

Mikushi 10y ago
I've had a bit of exposure to it (writing some HTTPS audit tool using Go\Crypto & some third party library - from CloudFlare) and I agree mostly, what struck me as a guy with 10+ years of PHP background is the speed at which I got the first versions of my tool out, really impressive. Definitely keen to may be transition to it if I can find stuff to do to better my knowledge of it. Have you found a decent way to deal with the dependency management, I found it a bit clunky...
- c2h5oh 10y ago
  Govendor + vendored dependencies in repo

waterside81 10y ago

Shipping self-hosted APIs is painless with Go thanks to how easy it is to cross-compile. Especially if your customers are enterprise and run Windows internally. Previously, we had to ship virtual appliances to our customers which then involved debugging their wacky network setups, their wacky version of VMWare etc. etc. Now it's just one liner build, upload to s3, send out a link, done.

manigandham 10y ago

You mean premature-optimization? That depends on the outcome. Would you call using C++ for developing a videogame as premature? Or just picking the right platform up front to meet the goals? Performance, especially efficiency, is way too often overlooked these days, and provides incredible benefits both for your own development, operations and end user experiences.

psiclops 10y ago

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%" I'd say picking a platform is not, as it is definitely a critical part of your program, especially if it does not greatly increase the complexity of your code.

devsquid 10y ago

Theres lots of reasons to use Go. Mine is the language is really stupid simple. Theres nothing fancy in the syntax, you can pick up a project you put down months ago and easily start working on it again