8 ms·

>Go is still my favorite language when it's the right tool for the job. Forgive my ignorance, when would you recommend go? As in what problem domains have you

>Go is still my favorite language when it's the right tool for the job. Forgive my ignorance, when would you recommend go? As in what problem domains have you seen it excel at? I have thought about trying it in the past and even tinkered with a project for a bit but didn't quite find it useful enough to be worth the tooling cost (at the time). Would like an excuse to check it out again.

fileeditview 6y ago
My guess is web servers for one, since he is the author of the Caddy web server (written in Go). Btw thanks for that.. I recently moved to a new VPS and migrated from nginx to Caddy.. I love it.
- mholt 6y ago
  Awesome, glad to hear it! :)
hellcow 6y ago
Not GP, but I choose Go for webservices as well as devops tooling. I use it whenever possible. I've been very happy with the decision to use Go over the past 4 years at my company.
mholt 6y ago
It's easy to learn and and great for getting something useful deployed pretty quickly. In both undergrad and grad school, I often chose Go and my projects -- using the same algorithms as classmates -- were finished sooner, ran faster, had less bugs, and used less resources. Go is pretty good for almost anything server-side. I wrote a web server in Go that a lot of businesses use in production. It's a very practical "get things done" language and is generally associated with developer satisfaction/happiness. Almost anywhere you use C/C++, I would try to use Go. It's progbably easier to enumerate what Go is not good at: native GUIs, C interop, some kinds of data science (though I used it as much as Python in college), and some kinds of very low-level programming (though it can be good for embedded systems, if you can stomach large binaries).
- systemvoltage 6y ago
  How can you do OOP with Go? I know it does some composition over inheritance but there 3 other aspects of OOP that I really like.
  - throwaway894345 6y ago
    Go is very opinionated and if you try to shoehorn it into some existing paradigm, you will probably not enjoy the experience. If you follow the happy-path, you'll have a much better time and for me at least, I decided that the things I liked about OOP were actually more elegantly addressed with Go. Notably decomposing inheritance into polymorphism (interfaces and callbacks), composition, and automatic delegation ("struct embedding")).
  - grey-area 6y ago
    You don't. Elaborate abstraction is often a mistake. Which aspects do you like? Personally I have grown to dislike the pointless abstraction and obfuscation introduced by huge inheritance hierarchies, so Go is a breath if fresh air in that regard in just doing away with it all. I haven't missed classes at all.
    - cutler 6y ago
      Go's structs with associated methods and property/method promotion aren't that different from classic OOP. Too much is made of the differences, I think. You can recreate most basic OOP code in Go .... if you really must.
      - grey-area 6y ago
        I do think it’s very different; types are not classes and interfaces are not like interfaces in java, obj-c for example, being defined at point of use. If you try to recreate inheritance in Go it will be frustrating and not very useful. The shape of the code ends up very different and embedding is not used even half as much as inheritance (which is the default position in most other oop languages). That has profound impacts.
jerf 6y ago
It's quite good at network code. Arguably, that's more because of the way you can pretty much completely rely on io.Reader and io.Writer being used pervasively throughout the ecosystem (3rd party libraries and all) rather than any specific "Go" special sauce, but, it is what it is.
- lanstin 6y ago
  The special sauce is you get work in from the network, split it into small pieces for a bunch of worker go routines and then make some of that work do down stream calls in easy to write CS 101 style network code; the go routines/channels exert back pressure exactly as you specify and the scheduler spreads the work across all the cores without you having to lock anything. And they have libraries for a bunch of modern things. Pretty good libraries too, written by people that care about error checking.
  - bombela 6y ago
    How do you apply back pressure? As far as I can tell Go will spawn a goroutine per request (well that's how the standard http lib and grpc seems to do it). I would like to compute a load factor and refuse new requests. Or do some basic rate limiting. But the coroutine is spawned before I have a say...
    - iampims 6y ago
      the package `netutil` has a LimitListener function which wraps the given listener and accepts at most N simultaneous connections.
    - jerf 6y ago
      In general, rate limiting of connections shouldn't take place in the server itself, it should be in some upstream load manager. If your system is too small to bother with that, it's almost certainly too small to worry about blowing out the goroutines. This is not a statement about Go, it's true in general. Even if you consult something per request, goroutines are fast enough to look at something and then decide not to do the work that, again, by the time that's a problem, the solution is to throttle upstream anyhow.
WinstonSmith84 6y ago
I like different languages and Rust most particularly, but when it's about getting things done, in a reliable way and within a short timeframe, I couldn't find yet a better trade off than Go.
codegeek 6y ago
I love Go for its native capabilities to do things with servers etc like ssh, networking. I wrote some Go code for a small project to connect to external servers using SSH and it was a lot of fun and a breeze.
u678u 6y ago
I like it because it creates a small binary executable that is easy to deploy. Other stuff like Java or Python have big VMs or interpreters that are error prone and take up room. Also if you want a small container a go binary is small.
pansa2 6y ago
I’ve considered Go for writing command-line apps - mostly for conversion between domain-specific formats and standard ones (e.g. proprietary image format => png). I think when considered in isolation, Go would be perfect for this. However, I haven’t used it because my existing code in this area is in C++ and I’m not sure how well the two languages interoperate.
- _ph_ 6y ago
  Go interoperates pretty well with C - so you would have to create a thin C layer on top of your C++ code. This is one problem I constantly have with C++, it is pretty much its own world. I have wrapped a large C++ library for Go it was a pretty straight forward process. I created a file with C callable functions that get passed pointers to the C++ objects and invoke the corresponding methods on that object. On the Go side pointer gets wrapped in a struct type for each C++ class and in the methods on that type I call the C functions. Works great.
  - pansa2 6y ago
    > I have wrapped a large C++ library for Go How well does it work the other way round - calling Go from C/C++? IIRC when I first looked into doing that, it wasn’t really possible - only threads that were started by Go could run Go code. In particular, `main` had to be in Go and couldn’t be in C++. Does that restriction still apply?
    - _ph_ 6y ago
      I have created shared libraries with Go which can be called from C, no problems. Those shared libraries can start their own goroutines quite fine and can call back into the C application. Usually it is a good idea to call back into the C application from the thread the Go function called from C was running.
      - eptcyka 6y ago
        Is there a way to bind a goroutine to a specific thread? Afaik, all C interop goes through a global lock because the runtime is weird.

fileeditview 6y ago

My guess is web servers for one, since he is the author of the Caddy web server (written in Go). Btw thanks for that.. I recently moved to a new VPS and migrated from nginx to Caddy.. I love it.

mholt 6y ago
Awesome, glad to hear it! :)

hellcow 6y ago

Not GP, but I choose Go for webservices as well as devops tooling. I use it whenever possible. I've been very happy with the decision to use Go over the past 4 years at my company.

mholt 6y ago

It's easy to learn and and great for getting something useful deployed pretty quickly. In both undergrad and grad school, I often chose Go and my projects -- using the same algorithms as classmates -- were finished sooner, ran faster, had less bugs, and used less resources. Go is pretty good for almost anything server-side. I wrote a web server in Go that a lot of businesses use in production. It's a very practical "get things done" language and is generally associated with developer satisfaction/happiness. Almost anywhere you use C/C++, I would try to use Go. It's progbably easier to enumerate what Go is not good at: native GUIs, C interop, some kinds of data science (though I used it as much as Python in college), and some kinds of very low-level programming (though it can be good for embedded systems, if you can stomach large binaries).

systemvoltage 6y ago
How can you do OOP with Go? I know it does some composition over inheritance but there 3 other aspects of OOP that I really like.
- throwaway894345 6y ago
  Go is very opinionated and if you try to shoehorn it into some existing paradigm, you will probably not enjoy the experience. If you follow the happy-path, you'll have a much better time and for me at least, I decided that the things I liked about OOP were actually more elegantly addressed with Go. Notably decomposing inheritance into polymorphism (interfaces and callbacks), composition, and automatic delegation ("struct embedding")).
- grey-area 6y ago
  You don't. Elaborate abstraction is often a mistake. Which aspects do you like? Personally I have grown to dislike the pointless abstraction and obfuscation introduced by huge inheritance hierarchies, so Go is a breath if fresh air in that regard in just doing away with it all. I haven't missed classes at all.
  - cutler 6y ago
    Go's structs with associated methods and property/method promotion aren't that different from classic OOP. Too much is made of the differences, I think. You can recreate most basic OOP code in Go .... if you really must.
    - grey-area 6y ago
      I do think it’s very different; types are not classes and interfaces are not like interfaces in java, obj-c for example, being defined at point of use. If you try to recreate inheritance in Go it will be frustrating and not very useful. The shape of the code ends up very different and embedding is not used even half as much as inheritance (which is the default position in most other oop languages). That has profound impacts.

jerf 6y ago

It's quite good at network code. Arguably, that's more because of the way you can pretty much completely rely on io.Reader and io.Writer being used pervasively throughout the ecosystem (3rd party libraries and all) rather than any specific "Go" special sauce, but, it is what it is.

lanstin 6y ago
The special sauce is you get work in from the network, split it into small pieces for a bunch of worker go routines and then make some of that work do down stream calls in easy to write CS 101 style network code; the go routines/channels exert back pressure exactly as you specify and the scheduler spreads the work across all the cores without you having to lock anything. And they have libraries for a bunch of modern things. Pretty good libraries too, written by people that care about error checking.
- bombela 6y ago
  How do you apply back pressure? As far as I can tell Go will spawn a goroutine per request (well that's how the standard http lib and grpc seems to do it). I would like to compute a load factor and refuse new requests. Or do some basic rate limiting. But the coroutine is spawned before I have a say...
  - iampims 6y ago
    the package `netutil` has a LimitListener function which wraps the given listener and accepts at most N simultaneous connections.
  - jerf 6y ago
    In general, rate limiting of connections shouldn't take place in the server itself, it should be in some upstream load manager. If your system is too small to bother with that, it's almost certainly too small to worry about blowing out the goroutines. This is not a statement about Go, it's true in general. Even if you consult something per request, goroutines are fast enough to look at something and then decide not to do the work that, again, by the time that's a problem, the solution is to throttle upstream anyhow.

WinstonSmith84 6y ago

I like different languages and Rust most particularly, but when it's about getting things done, in a reliable way and within a short timeframe, I couldn't find yet a better trade off than Go.

codegeek 6y ago

I love Go for its native capabilities to do things with servers etc like ssh, networking. I wrote some Go code for a small project to connect to external servers using SSH and it was a lot of fun and a breeze.

u678u 6y ago

I like it because it creates a small binary executable that is easy to deploy. Other stuff like Java or Python have big VMs or interpreters that are error prone and take up room. Also if you want a small container a go binary is small.

pansa2 6y ago

I’ve considered Go for writing command-line apps - mostly for conversion between domain-specific formats and standard ones (e.g. proprietary image format => png). I think when considered in isolation, Go would be perfect for this. However, I haven’t used it because my existing code in this area is in C++ and I’m not sure how well the two languages interoperate.

_ph_ 6y ago
Go interoperates pretty well with C - so you would have to create a thin C layer on top of your C++ code. This is one problem I constantly have with C++, it is pretty much its own world. I have wrapped a large C++ library for Go it was a pretty straight forward process. I created a file with C callable functions that get passed pointers to the C++ objects and invoke the corresponding methods on that object. On the Go side pointer gets wrapped in a struct type for each C++ class and in the methods on that type I call the C functions. Works great.
- pansa2 6y ago
  > I have wrapped a large C++ library for Go How well does it work the other way round - calling Go from C/C++? IIRC when I first looked into doing that, it wasn’t really possible - only threads that were started by Go could run Go code. In particular, `main` had to be in Go and couldn’t be in C++. Does that restriction still apply?
  - _ph_ 6y ago
    I have created shared libraries with Go which can be called from C, no problems. Those shared libraries can start their own goroutines quite fine and can call back into the C application. Usually it is a good idea to call back into the C application from the thread the Go function called from C was running.
    - eptcyka 6y ago
      Is there a way to bind a goroutine to a specific thread? Afaik, all C interop goes through a global lock because the runtime is weird.