10 ms·

There have been several blog posts and conference presentations with a similar theme -- "Go is efficient, especially compared to X." I know it seems like hype,

There have been several blog posts and conference presentations with a similar theme -- "Go is efficient, especially compared to X." I know it seems like hype, but I encourage others to try Golang out, maybe even slap a web app together with it. What you'll find is that your Go app will be extremely efficient and performant. It's kind of unfair to compare Go to many of the other languages of the web because it is compiled, which is a huge reason why it is so performant. So rather than compare Go to other languages, I encourage you all to give it a try. If you already program, working on a small Go side project will get you up to speed quickly and you'll learn about some of the awesome packages individuals from the Go community have put together for us. Disclaimer: I do not work for Google. I write Go code and enjoy it. I think others will too.

eropple 11y ago
> What you'll find is that your Go app will be extremely efficient and performant. This is true, for sure. But my experience--and I've written plenty of Go, though I find it unpleasant to write and think about for all the usual reasons that Go partisans roll their eyes and so would rather deal with it as artifacts rather than actually writing it--has led to watching lots of developers make mudball codebases in the process (while blogging very heavily about how great it is three weeks in, and less a year-plus in). A pursuit of faux-simplicity has led to what I see as reinventing a lot of Java-1.4-era (because the language itself is essentially that) design patterns--and we should be reminded that design patterns exist to address defects in tooling--that more expressive languages have managed to avoid; the general desire for smaller applications helps to some extent, but software has this tendency to grow that I don't think Go gives you the tools to effectively manage and maintain. Reasonable minds can differ, of course. Past that, while I think it's an alright choice for company-internal deployable products--web servers, worker nodes, etc.--I have straight-up problems with it being the new devops tool of choice. Statically linking your SSL library makes you an asshole when it inevitably fails and now an application has to be regression-tested so that new features and new bugs don't hose you just because that's the only way to upgrade Heartbleed 2.0. (Go also discourages program extensibility through components and rather as recompilation; the stuff Packer and Terraform do to provide "plugins" that the same company's Vagrant just did with a `require` is gross and, to my mind, completely foolish.) So I wouldn't say it's hype, but I would say it's not all true, either.
- Conlectus 11y ago
  > Go also discourages program extensibility through components Can you elaborate on this? Because in my experience with Go, I found that I had to make _far_ more components (assuming this means libraries?) than other languages. > Statically linking your SSL library makes you an asshole when it inevitably fails and now an application has to be regression-tested so that new features and new bugs don't hose you just because that's the only way to upgrade Heartbleed 2.0 Not sure I understand that last bit. I get that statically linking could be bad(ish) because you would need to know to recompile with a fixed library, but what was that about new features?
  - stock_toaster 11y ago
    I think the parent was saying that new releases would bring new features the end user may not want, in addition to something like a security fix for an included library. With shared libs, you can keep using an old version if it works for you, while still updating ssl to a fixed version (assuming api compat).
    - eropple 11y ago
      This, precisely. If I have to compile YourApp 1.5 with YourTLSLib instead of just `apt-get upgrade`, I'm going to be sending you flaming karmic poop for your karmic doorstep. And not just new features--though SemVer is very often honored in the breach more than the observance--but breaking, sometimes undocumented changes (two Go projects, Packer and Terraform, both come to mind).
      - kjksf 11y ago
        `apt-get upgrade` is not magic. Someone had to package the app for apt. Someone had to decide when to make a new release. The same can be done for a Go app and it'll be available via apt just as any other app. A fair comparison would be compiling a C/C++ app from sources vs. compiling Go app from sources and Go wins that contest easily.
omginternets 11y ago
I think Go invites comparison to dynamically typed languages because it's compiler is so damn fast. Yes, Go is technically compiled, but the development cycle is closer to that of dynamic languages. In a similar vein, I have a lot of trouble taking criticism of Go's type system seriously. Is it as robust as Rust's? Probably not (I've never used Rust), but that's way beside the point. Go's type system gives you a great deal of benefits while keeping the language very dynamic-y. tl;dr: haters gonna hate. I like Go very much for certain things.
- deleted 11y ago
  [deleted]
- swah 11y ago
  Me too. Some folks prefer to think instead of messing with the code and retesting. I hate it.
  - omginternets 11y ago
    I honestly prefer to do both. Picking the right tool for the job implies that you've thought a great deal about your requirements. Plus thinking is an enjoyable and rewarding experience.
- nickpsecurity 11y ago
  That's definitely an advantage. People used to rag on me because I used a BASIC dialect for most of my development. One of main reasons: tens to hundreds of thousands of lines of code compiled and linked effortlessly. I later moved to LISP with its incremental, function-by-function compilation to get pause times down to tenth of a second. Either way, the elimination of long compile cycles and other interruptions maintains the mental flow of the programmer. This results in a significant productivity boost. Also, the job feels better as interruptions and backtracking can be stressful.
  - omginternets 11y ago
    One of my colleagues (a Paris Politechnique guy, so very much a mathematical purist) was recently going on and on about the beauty of lisp, and how much better it was than C (on a formal level, of course). I think Go sits on the opposite end of the spectrum. It's a hacker's language, not a mathematician's language. It's ugly and very useful.
eternalban 11y ago
I prototyped a cache in Go and the ref. impl. in C. I'm a long time Go coder but did not expect the Go prototype to run so damn close to the C (and for certain ops actually faster than C). The runtime is shaping up quite nicely. Given dynamic linking and this language can pretty much pull its weight in the backend for almost anything.
vardump 11y ago
I wrote a small/medium size, non-trivial tcp-server in golang two years ago, in just about 2-3 weeks. It pretty much worked first try! So far 2 minor bugs. Originally it was meant to be just a quick kick-golang-tires prototype, to be replaced with C++ later, but it turned out to work really well. My impression of golang is that it's very useful getting things done. The code has also been readable to other people pretty much immediately, and they've been able to contribute features into it. None of us used golang previously. Had I written same in C++, I bet there'd been a lot more bugs to fix.
vorg 11y ago
> slap a web app together with it Web apps are on the decline, being gradually replaced by Android/iOS apps. When people can use Go to slap up a performant Android app, it may find more use.
- StavrosK 11y ago
  What are these mobile apps that don't have Web backends?
- mkawia 11y ago
  So slap an http api ? Building native apps is hard unless you are specialized , but puking up some html and json is easy ,hence building a blog is usually good for introduction.
- coldtea 11y ago
  Nobody cares about Android apps. And they ain't gonna make you rich. Neither will iOS apps for that matter. That's a market raced to the bottom, that only makes sense for a few top players. The web is not going away anytime soon.
duaneb 11y ago
Go is only a massive improvement over interpreted languages. Anyone who was already writing performance software will have a much harder time justifying the switch: many low and high level features are simply not in the language. (E.g. parametric types, macros, a runtime using a c-like stack, avoiding the GC).

eropple 11y ago

> What you'll find is that your Go app will be extremely efficient and performant. This is true, for sure. But my experience--and I've written plenty of Go, though I find it unpleasant to write and think about for all the usual reasons that Go partisans roll their eyes and so would rather deal with it as artifacts rather than actually writing it--has led to watching lots of developers make mudball codebases in the process (while blogging very heavily about how great it is three weeks in, and less a year-plus in). A pursuit of faux-simplicity has led to what I see as reinventing a lot of Java-1.4-era (because the language itself is essentially that) design patterns--and we should be reminded that design patterns exist to address defects in tooling--that more expressive languages have managed to avoid; the general desire for smaller applications helps to some extent, but software has this tendency to grow that I don't think Go gives you the tools to effectively manage and maintain. Reasonable minds can differ, of course. Past that, while I think it's an alright choice for company-internal deployable products--web servers, worker nodes, etc.--I have straight-up problems with it being the new devops tool of choice. Statically linking your SSL library makes you an asshole when it inevitably fails and now an application has to be regression-tested so that new features and new bugs don't hose you just because that's the only way to upgrade Heartbleed 2.0. (Go also discourages program extensibility through components and rather as recompilation; the stuff Packer and Terraform do to provide "plugins" that the same company's Vagrant just did with a `require` is gross and, to my mind, completely foolish.) So I wouldn't say it's hype, but I would say it's not all true, either.

Conlectus 11y ago
> Go also discourages program extensibility through components Can you elaborate on this? Because in my experience with Go, I found that I had to make _far_ more components (assuming this means libraries?) than other languages. > Statically linking your SSL library makes you an asshole when it inevitably fails and now an application has to be regression-tested so that new features and new bugs don't hose you just because that's the only way to upgrade Heartbleed 2.0 Not sure I understand that last bit. I get that statically linking could be bad(ish) because you would need to know to recompile with a fixed library, but what was that about new features?
- stock_toaster 11y ago
  I think the parent was saying that new releases would bring new features the end user may not want, in addition to something like a security fix for an included library. With shared libs, you can keep using an old version if it works for you, while still updating ssl to a fixed version (assuming api compat).
  - eropple 11y ago
    This, precisely. If I have to compile YourApp 1.5 with YourTLSLib instead of just `apt-get upgrade`, I'm going to be sending you flaming karmic poop for your karmic doorstep. And not just new features--though SemVer is very often honored in the breach more than the observance--but breaking, sometimes undocumented changes (two Go projects, Packer and Terraform, both come to mind).
    - kjksf 11y ago
      `apt-get upgrade` is not magic. Someone had to package the app for apt. Someone had to decide when to make a new release. The same can be done for a Go app and it'll be available via apt just as any other app. A fair comparison would be compiling a C/C++ app from sources vs. compiling Go app from sources and Go wins that contest easily.

omginternets 11y ago

I think Go invites comparison to dynamically typed languages because it's compiler is so damn fast. Yes, Go is technically compiled, but the development cycle is closer to that of dynamic languages. In a similar vein, I have a lot of trouble taking criticism of Go's type system seriously. Is it as robust as Rust's? Probably not (I've never used Rust), but that's way beside the point. Go's type system gives you a great deal of benefits while keeping the language very dynamic-y. tl;dr: haters gonna hate. I like Go very much for certain things.

deleted 11y ago
[deleted]
swah 11y ago
Me too. Some folks prefer to think instead of messing with the code and retesting. I hate it.
- omginternets 11y ago
  I honestly prefer to do both. Picking the right tool for the job implies that you've thought a great deal about your requirements. Plus thinking is an enjoyable and rewarding experience.
nickpsecurity 11y ago
That's definitely an advantage. People used to rag on me because I used a BASIC dialect for most of my development. One of main reasons: tens to hundreds of thousands of lines of code compiled and linked effortlessly. I later moved to LISP with its incremental, function-by-function compilation to get pause times down to tenth of a second. Either way, the elimination of long compile cycles and other interruptions maintains the mental flow of the programmer. This results in a significant productivity boost. Also, the job feels better as interruptions and backtracking can be stressful.
- omginternets 11y ago
  One of my colleagues (a Paris Politechnique guy, so very much a mathematical purist) was recently going on and on about the beauty of lisp, and how much better it was than C (on a formal level, of course). I think Go sits on the opposite end of the spectrum. It's a hacker's language, not a mathematician's language. It's ugly and very useful.

eternalban 11y ago

I prototyped a cache in Go and the ref. impl. in C. I'm a long time Go coder but did not expect the Go prototype to run so damn close to the C (and for certain ops actually faster than C). The runtime is shaping up quite nicely. Given dynamic linking and this language can pretty much pull its weight in the backend for almost anything.

vardump 11y ago

I wrote a small/medium size, non-trivial tcp-server in golang two years ago, in just about 2-3 weeks. It pretty much worked first try! So far 2 minor bugs. Originally it was meant to be just a quick kick-golang-tires prototype, to be replaced with C++ later, but it turned out to work really well. My impression of golang is that it's very useful getting things done. The code has also been readable to other people pretty much immediately, and they've been able to contribute features into it. None of us used golang previously. Had I written same in C++, I bet there'd been a lot more bugs to fix.

vorg 11y ago

> slap a web app together with it Web apps are on the decline, being gradually replaced by Android/iOS apps. When people can use Go to slap up a performant Android app, it may find more use.

StavrosK 11y ago
What are these mobile apps that don't have Web backends?
mkawia 11y ago
So slap an http api ? Building native apps is hard unless you are specialized , but puking up some html and json is easy ,hence building a blog is usually good for introduction.
coldtea 11y ago
Nobody cares about Android apps. And they ain't gonna make you rich. Neither will iOS apps for that matter. That's a market raced to the bottom, that only makes sense for a few top players. The web is not going away anytime soon.

duaneb 11y ago

Go is only a massive improvement over interpreted languages. Anyone who was already writing performance software will have a much harder time justifying the switch: many low and high level features are simply not in the language. (E.g. parametric types, macros, a runtime using a c-like stack, avoiding the GC).