7 ms·

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 -- us

by 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.
      - pjmlp 6y ago
        It is basically Component Based Programming, started with Objective-C protocols, Smalltalk categories, Java/.NET interfaces, COM ABI. inheritance is just like in COM via delegation and struct embedding.
- sheenobu 6y ago
  Go can do encapsulation and polymorphism. Go doesn't do inheritance, of course. Channels can also help simulate message passing and actor-style code. What's missing? IMO, If you compare Go to an OOP language that runs in a VM there are some things that will fall short but the industry has worked around it. It's not cool to have a beefy Smalltalk or Java VM, with the dynamic runtimes that let you auto-export objects as remote endpoints... you have small binaries exporting HTTP or RPC services running in containers and interfacing with service discovery and fabric systems. The "object orientation" is now at an abstraction sitting above the running binary.
  - douglasisshiny 6y ago
    >It's not cool to have a beefy Smalltalk or Java VM, with the dynamic runtimes that let you auto-export objects as remote endpoints... you have small binaries exporting HTTP or RPC services running in containers and interfacing with service discovery and fabric systems. The "object orientation" is now at an abstraction sitting above the running binary. I'm not sure why an application running in the JVM in a container is any different. Can you elaborate?
    - sheenobu 6y ago
      Running a JVM application in a container is not all that different to running a Go application in a container. But the design of the JVM runtime and its tooling is vastly different than Go. The JVM is more complex but it can do more things. Go is simpler and can get you to a working product quicker. If someone asks me to build something and they tell me it will run in docker/kubernetes, have the standard containerized CI pipelines, and communicate with other services over some standard protocol like HTTP; doing it on the JVM is doable and probably easier than ever but I would just think about all the cool JVM features I wouldn't get to use (hot code deploy, runtime modularity tools, all the neat bytecode hacks, even spring which everyone but me seems to hate). If I don't get to use those features then I would rather grab a language like Go, since it doesn't front load so many runtime complexities. (and if this was 10-15 years ago maybe I'd say "Go doesn't front load so many complexities AND performance penalties")
- naikrovek 6y ago
  Don't. OOP was/is a mistake.
  - gher-shyu3i 6y ago
    Golang is OOP, regardless of what some people may claim. It's just missing inheritance, which golang's implementation of composition mimics it close enough.
    - grey-area 6y ago
      Composition is not a substitute for inheritance and is used an order of magnitude less in Go code than inheritance in other languages, which touches everything.
      - pjmlp 6y ago
        It is close enough when coupled with delegation. That is how component based programming works.
        grey-area 6y ago
        The important point is it is used far less - inheritance is impossible to get away from in most OOP programs, but you can't say the same for embedding in Go programs, it is used, but not as often.
        pjmlp 6y ago
        It is only impossible because you cannot throw away standard libraries. COM/UWP have proven you don't need to have it available. They get lots of hate due to their underlying complexity, however they are the main Windows APIs since Vista, as COM took over the Longhorn vision.
- cutler 6y ago
  Go supports a slimmed-down version of OOP compared with Java/C# via property and method "promotion". There are no static properties/methods and no abstract classes but you have interfaces with Ruby-esque duck typing. I've omitted generics as that's due in Go 2.0. I find listing methods beneath their corresponding struct definition to be quite adequate when OOP is the best fit .... which isn't that often. I just finished implementing most of the functionality in Matt Zandstra's "PHP Objects, Patterns, Practice", 5th edition, in Go and didn't miss much.
KarlKode 6y ago
Do you know any good GUI library in go (as you mention native GUIs as a weakness. Besides that what were you're problems with the C interop? In addition to the lack of up to date documentation for more complicated examples, I had huge problems using the C interop layer with more complicated C++ libraries (mostly because the C interop has its problems with C++).
- sly010 6y ago
  C++ doesn't have a stable ABI, so C++ interop is usually done by wrapping a C++ library with a C interface first. This is true for most compiled languages afaik. GUI libraries often rely on specific language features so they are hard to wrap in other languages. That's why good GUI libraries don't exist in ANY language other than the ones they were written in.
  - _ph_ 6y ago
    I think GUI libraries which offer C bindings are easy to wrap in other languages, that is why I like Gtk a lot. In my eyes, it works especially nice with Go. Tk should be easy to wrap for Go to, but usually one would prefer Gtk, when there is a choice :).
- _ph_ 6y ago
  I have been quite happy with the Gtk bindings for Go (https://github.com/gotk3/gotk3 https://github.com/gotk3/gotk3). As Gtk has a C Api, it is a good match for Go, actually Go makes Gtk nicer than calling it from C in my eyes, as the GObject wrap to Go types and you can just call methods on them vs. the C syntax of passing the GObject as the first function argument and having the object type in the function name. If you install the Gtk libraries on the Mac, Go programs written with gotk3 just compile and run there too.
- xyzzy_plugh 6y ago
  Gio is coming along nicely. Once they go full tile-based-rasterization ala Pathfinder it'll be a contender. https://gioui.org https://gioui.org
- 6y ago
MuffinFlavored 6y ago
> It's easy to learn and and great for getting something useful deployed pretty quickly I'd argue node.js is even easier to learn and even better for getting something useful deployed faster.
- nine_k 6y ago
  If you want a single-binary utility, node has a disadvantage.
- FpUser 6y ago
  My understanding is that one can deploy go application simply by copying. Can't get much simpler than that.
  - matwood 6y ago
    I know it's not magic, but is so nice when I build my go utility on my Mac with a linux target, copy it and its config to a linux server, and it runs. After dealing with setting up java, node, and python envs for so many years, go is a breath of fresh air on the deployment side.
    - FpUser 6y ago
      I've been doing native applications something like forever and all those apps are exactly the same way. Just copy and enjoy. I just do not understand fun of "modern" apps where the amount of tooling and configuration will drive one straight to insanity.
- rad_gruchalski 6y ago
  The advantage of nodejs over go for web apps is the live reload / recompile tool chain. golang has some really nice apis for back end servers, single binary, no runtime deployment is really great. But golang lacks in that live reload feedback loop. I do a lot of golang but whenever I want to do something web browser facing, I cave in for nodejs. Especially in the exploratory phase when building front / back end together.
alienspaces 6y ago
"Go is pretty good for almost anything server-side." Absolutely! REST API servers, data processing jobs, messaging servers, etc etc. I use Go now for virtually everything server side. It is fast, reliable, great tooling, promotes unit testing, and now that I have hit that "comfortable with the language" spot, I have never been more productive.

by mholt 6y ago

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.
    - pjmlp 6y ago
      It is basically Component Based Programming, started with Objective-C protocols, Smalltalk categories, Java/.NET interfaces, COM ABI. inheritance is just like in COM via delegation and struct embedding.
sheenobu 6y ago
Go can do encapsulation and polymorphism. Go doesn't do inheritance, of course. Channels can also help simulate message passing and actor-style code. What's missing? IMO, If you compare Go to an OOP language that runs in a VM there are some things that will fall short but the industry has worked around it. It's not cool to have a beefy Smalltalk or Java VM, with the dynamic runtimes that let you auto-export objects as remote endpoints... you have small binaries exporting HTTP or RPC services running in containers and interfacing with service discovery and fabric systems. The "object orientation" is now at an abstraction sitting above the running binary.
- douglasisshiny 6y ago
  >It's not cool to have a beefy Smalltalk or Java VM, with the dynamic runtimes that let you auto-export objects as remote endpoints... you have small binaries exporting HTTP or RPC services running in containers and interfacing with service discovery and fabric systems. The "object orientation" is now at an abstraction sitting above the running binary. I'm not sure why an application running in the JVM in a container is any different. Can you elaborate?
  - sheenobu 6y ago
    Running a JVM application in a container is not all that different to running a Go application in a container. But the design of the JVM runtime and its tooling is vastly different than Go. The JVM is more complex but it can do more things. Go is simpler and can get you to a working product quicker. If someone asks me to build something and they tell me it will run in docker/kubernetes, have the standard containerized CI pipelines, and communicate with other services over some standard protocol like HTTP; doing it on the JVM is doable and probably easier than ever but I would just think about all the cool JVM features I wouldn't get to use (hot code deploy, runtime modularity tools, all the neat bytecode hacks, even spring which everyone but me seems to hate). If I don't get to use those features then I would rather grab a language like Go, since it doesn't front load so many runtime complexities. (and if this was 10-15 years ago maybe I'd say "Go doesn't front load so many complexities AND performance penalties")
naikrovek 6y ago
Don't. OOP was/is a mistake.
- gher-shyu3i 6y ago
  Golang is OOP, regardless of what some people may claim. It's just missing inheritance, which golang's implementation of composition mimics it close enough.
  - grey-area 6y ago
    Composition is not a substitute for inheritance and is used an order of magnitude less in Go code than inheritance in other languages, which touches everything.
    - pjmlp 6y ago
      It is close enough when coupled with delegation. That is how component based programming works.
      - grey-area 6y ago
        The important point is it is used far less - inheritance is impossible to get away from in most OOP programs, but you can't say the same for embedding in Go programs, it is used, but not as often.
        pjmlp 6y ago
        It is only impossible because you cannot throw away standard libraries. COM/UWP have proven you don't need to have it available. They get lots of hate due to their underlying complexity, however they are the main Windows APIs since Vista, as COM took over the Longhorn vision.
cutler 6y ago
Go supports a slimmed-down version of OOP compared with Java/C# via property and method "promotion". There are no static properties/methods and no abstract classes but you have interfaces with Ruby-esque duck typing. I've omitted generics as that's due in Go 2.0. I find listing methods beneath their corresponding struct definition to be quite adequate when OOP is the best fit .... which isn't that often. I just finished implementing most of the functionality in Matt Zandstra's "PHP Objects, Patterns, Practice", 5th edition, in Go and didn't miss much.

KarlKode 6y ago

Do you know any good GUI library in go (as you mention native GUIs as a weakness. Besides that what were you're problems with the C interop? In addition to the lack of up to date documentation for more complicated examples, I had huge problems using the C interop layer with more complicated C++ libraries (mostly because the C interop has its problems with C++).

sly010 6y ago
C++ doesn't have a stable ABI, so C++ interop is usually done by wrapping a C++ library with a C interface first. This is true for most compiled languages afaik. GUI libraries often rely on specific language features so they are hard to wrap in other languages. That's why good GUI libraries don't exist in ANY language other than the ones they were written in.
- _ph_ 6y ago
  I think GUI libraries which offer C bindings are easy to wrap in other languages, that is why I like Gtk a lot. In my eyes, it works especially nice with Go. Tk should be easy to wrap for Go to, but usually one would prefer Gtk, when there is a choice :).
_ph_ 6y ago
I have been quite happy with the Gtk bindings for Go (https://github.com/gotk3/gotk3 https://github.com/gotk3/gotk3). As Gtk has a C Api, it is a good match for Go, actually Go makes Gtk nicer than calling it from C in my eyes, as the GObject wrap to Go types and you can just call methods on them vs. the C syntax of passing the GObject as the first function argument and having the object type in the function name. If you install the Gtk libraries on the Mac, Go programs written with gotk3 just compile and run there too.
xyzzy_plugh 6y ago
Gio is coming along nicely. Once they go full tile-based-rasterization ala Pathfinder it'll be a contender. https://gioui.org https://gioui.org
6y ago

MuffinFlavored 6y ago

> It's easy to learn and and great for getting something useful deployed pretty quickly I'd argue node.js is even easier to learn and even better for getting something useful deployed faster.

nine_k 6y ago
If you want a single-binary utility, node has a disadvantage.
FpUser 6y ago
My understanding is that one can deploy go application simply by copying. Can't get much simpler than that.
- matwood 6y ago
  I know it's not magic, but is so nice when I build my go utility on my Mac with a linux target, copy it and its config to a linux server, and it runs. After dealing with setting up java, node, and python envs for so many years, go is a breath of fresh air on the deployment side.
  - FpUser 6y ago
    I've been doing native applications something like forever and all those apps are exactly the same way. Just copy and enjoy. I just do not understand fun of "modern" apps where the amount of tooling and configuration will drive one straight to insanity.
rad_gruchalski 6y ago
The advantage of nodejs over go for web apps is the live reload / recompile tool chain. golang has some really nice apis for back end servers, single binary, no runtime deployment is really great. But golang lacks in that live reload feedback loop. I do a lot of golang but whenever I want to do something web browser facing, I cave in for nodejs. Especially in the exploratory phase when building front / back end together.

alienspaces 6y ago

"Go is pretty good for almost anything server-side." Absolutely! REST API servers, data processing jobs, messaging servers, etc etc. I use Go now for virtually everything server side. It is fast, reliable, great tooling, promotes unit testing, and now that I have hit that "comfortable with the language" spot, I have never been more productive.