6 ms·

Go isn't a perfect language, but it strikes the right balance for me between productivity and safety. There are few other languages right now with the same ease

by be_erik 10y ago

Go isn't a perfect language, but it strikes the right balance for me between productivity and safety. There are few other languages right now with the same ease of deployment, good tooling, excellent standard lib, and raw performance. Here's to another seven years.

72deluxe 10y ago
Out of interest, can you point me to any GUI bindings or native Go GUI toolkits etc.? I would like to take a look, as I am normally writing native C++ GUI desktop apps. EDIT: Thanks for all the info everyone. I hope my responses don't appear argumentative - I am genuinely curious.
- 0xmohit 10y ago
  I haven't tried it thus far, but you can see a list at the Projects wiki [0]. [0] https://github.com/golang/go/wiki/Projects#guis-and-widget-toolkits https://github.com/golang/go/wiki/Projects#guis-and-widget-t...
- Klathmon 10y ago
  I'm not sure if this would work for you, but using something like Electron and having your go program output HTML/JS/CSS as your UI works really well with go (or have your go program output JSON or something to communicate with the front end) If you throw something like react on there, you'll have a pretty simple functional UI, but if you don't want that there's nothing wrong with HTML/CSS and as little JS as you can get away with.
  - 72deluxe 10y ago
    That sounds an interesting concept and useful for creating instantly-usable web apps but in effect isn't your Go app being relegated to a HTTP server? eg. how would I do callbacks without doing them as some request back to the Go "server" app? How would you create custom controls in this method? eg. if I wanted to do my own pie chart control/widget with popups etc. It sounds like a long way around in comparison to what you can do in C/C++, ie native calls depending on the platform, or use an abstraction toolkit like wxWidgets. (Oddly C++ has done well without any native GUI toolkit of course, but at least there was native C ones to use).
    - Klathmon 10y ago
      Ideally you would put as much of the "business logic" in the go code as possible, and have it "render" to something like JSON which the front end just reads in and displays. Interactions with the front-end just send a new request to the go code to handle and respond with what is needed. It is a lot more work for small applications compared to something like wxWidgets, but for larger applications the decoupling of the front end from the "back end" can help in a bunch of ways. It lets you develop them somewhat separately, it gives you a uniform look-and-feel across platforms (could be a pro or a con depending on how you feel about it), and allows you to do something like replace the web-front-end with a native system later if you want (and you could write the front-end in the platform's native GUI widget library for best performance and integration while keeping the backend code identical). So your go code is basically an HTTP server at that point, but it frees you up to let go do what it does best without worrying about how you will display it, and it lets javascript/html/css do what it does best (display stuff). I've had great success doing this once before, and if you have some experience with React, it works out really "beautifully" as the front-end can be completely stateless. So what was pushed to it from go is what is displayed. Easy to test, easy to develop, and easy to replace if needed.
    - pjmlp 10y ago
      > Oddly C++ has done well without any native GUI toolkit of course, Well from the OS vendors themselves we had MFC/WTL/Windows Forms/WTL on Windows, BeOS GUI, Symbian UI, CSet++ on OS/2, PowerPlant on Mac. Additionally there was Turbo Vision on MS-DOS, OWL, VCL for Windows, Motif++ on UNIX.
- dilap 10y ago
  I love Go and think it could be good in this area, but so far as I know no one is using it for any serious GUI work (yet?).
  - 72deluxe 10y ago
    What is it being used for? HTTP servers? 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere?
    - vram22 10y ago
      >What is it being used for? HTTP servers? Yes, that is one big area - networked servers - a superset of HTTP servers. The Google site that serves the Chrome browser is supposed to be a Go app, and I've read Google uses Go a lot internally. (I'm sure Rob Pike and his team must be using it, after developing it for that very purpose.) Reading up on the goals of Go will give some insight into that. Part of the reason was that they wanted it to write big systems at Google, including networked ones, and wanted a better experience than they had with C++ (build times [1] and also other issues). Rob Pike has written some about it, others may have too). [1] This video that I blogged about: Video: C++, Rust, D and Go: Panel at LangNext '14: http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-panel-at-langnext.html http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-pane... has many interesting language-related discussions; one of them is the discussion about the build times of C++ vs. those of more modern language. There are concrete reasons why C++ build times are relatively so large - the use of include files is part of the reason - those are discussed some in the video, between the panelists, including some of the language (co-)inventors, such as C++'s Bjarne Stroustrup, Go's Rob Pike and D's Walter Bright. There is a nice moment or two near the end where Stroustrup responds about C++ build times - okay, won't spoil it for you and others - go see it :) Command-line tools is another area where Go is used a lot. Getting the convenience of deploying a simple single binary (maybe at the most a config file or two with it) even by just copying to the deploy target - unlike what you have to do with interpreted languages like Python and Ruby (unless you use something like PyInstaller or py2exe for Python, but that is not officially supported and may or not work for all Python apps [2]). This gives us back some of the convenience of older compiled languages like C where this was the normal way of deploying - but with some benefits over languages such as C (see Go vs. C topics), plus goroutines, channels, etc., I guess. Though I have not come across any examples of what things command line apps using goroutines and channels could be used for - it would be interesting to hear/read about some. I mean apart from a few somewhat obvious ones such as a web client to download multiple URLs in different goroutines, concurrently. [2] I've tried out PyInstaller on a few Python apps, including command-line apps, and a simple wxPython app or two - it did work okay for those, in the limited testing I did. Edit: fixed typos, added a few points.
- gribbly 10y ago
  I'm certain there are more, but here are a few platform native https://github.com/andlabs/ui https://github.com/andlabs/ui gtk http://mattn.github.io/go-gtk/ http://mattn.github.io/go-gtk/ qt https://github.com/therecipe/qt https://github.com/therecipe/qt qml https://github.com/go-qml/qml https://github.com/go-qml/qml shiny (still being developed, Go native) https://github.com/golang/exp/tree/master/shiny https://github.com/golang/exp/tree/master/shiny
- vram22 10y ago
  Here is one - WALK: https://github.com/lxn/walk https://github.com/lxn/walk A friend had used it in a commercial project, and IIRC he said it worked okay. Not tried it myself yet. I think it wraps the Win32 GUI SDK but also has a declarative mode [1] (at least for GUI widget layout) on top, or something like that - only looked at some sample code briefly. [1] meaning you can declare your GUI layout declaratively, but in Go code - it does not need XML or some other language or markup format like some declarative approaches do - IIRC. I actually wish the Go team had built support for some / many of the major GUI toolkits on major OS's (at least) from near the start of Go's development. I realize that there could have been, or still could be, some issues with that, due to differences between Go and (C and C++) [2] models (object file format, calling conventions, stack and heap layout, etc. - basically compiler and compiler-output-related stuff), and hence it may not be easy to create bindings from the former to the latter. Not familiar with this area. [2] since many of the major GUI toolkits are natively written in C or C++, so a Go wrapper would need to bind to them. Not complaining though, I know what they (the Go team and community) have already done is a huge achievement anyway.
wyager 10y ago
How is Go safer than, say, Java? It doesn't really do anything particularly useful or interesting on the safety front; it's type system is weak, it has null pointers, its error management mechanisms are mediocre.
- weberc2 10y ago
  It's not safer than Java. The selling point over Java is developer friendliness (simpler language, tooling, dependency management, deployment, etc).
  - tigershark 10y ago
    no. I really don't like java, but you really can't tell that go has better tooling and it is more developer friendly. it's an outright lie. java tooling is very mature and has solutions that no other language that I know can use. (Spock framework above all, it is written in groovy but it is perfectly integrated in java and still I haven't find anything nearly comparable in any other language). show me some BDD framework in go, just as an example.
    - vorg 10y ago
      > Spock framework above all, it is written in groovy You're the one who's telling an "outright lie" (as you put it). I just downloaded and unzipped Spock from Github, and looked through its directory structure. Virtually all of it is written in Java, not Apache Groovy. There's only a few little files written in Groovy. Perhaps you're confusing its source language with the language users of Spock write their test scripts in. In real life, Groovy is used for the JVM in the same way Bash is used for Linux, like writing glue code and build files. The statically typed stuff added in Groovy 2.x isn't used much at all, and virtually no-one would use Groovy to build actual systems. All software I know of that provides Groovy to users, like Grails, Gradle, and Spock, is itself written in Java.
  - wyager 10y ago
    I was asking the GP why he cited safety as a feature of Go. I agree with you; that's not a good argument.
AsyncAwait 10y ago
> strikes the right balance for me between productivity and safety. Would be curious to hear what "safety" you're referring to, is it just that it has a basic static type system, (which is constantly being undermined by interface{} and reflection), or is there more to it? Genuinely curious.
- chmike 10y ago
  Compared to C it is safer. I never saw a segmentation fault, only some panic errors with bound checking. I prefer go to python or javascipt. It's far too easy to make errors in them. Minimal static code checking.
  - AsyncAwait 10y ago
    > compared to C it is safer. I never saw a segmentation fault Well, yeah, it has a GC so it kind of gets that "automatically", I was thinking more about the type system side of things. And compared to C almost anything is indeed safer. > I prefer go to python or javascipt. It's far too easy to make errors in them. That's fair, but these are both dynamic languages, so almost anything with any level of static typing beats them in this regard, I was interested if Go does anything beyond that. Not to say these are not fair points, but nothing a whole host of other languages haven't provided before Go.
    - chmike 10y ago
      Not only static typing. I just found a bug in an open source python tool that crashed because of a missing member variable in a class. You have to assign a value in the attribute to create it. It requires careful programming to not get such errors. It is also easy to accidentaly create a member variable. The time you gain by being able to hack some code together is lost by these types of error unless you are a very disciplined programmer. Another kind of error with python is with blocks defined by vertical alignment. It is easy to make errors when you copy past code and the alignment is not corrected. When you are under pressure or tired, your discipline may weaken. And this is difficult for inexperienced programmers. You don't have these problems with go and the normalized formating helps a lot.

by be_erik 10y ago

72deluxe 10y ago

Out of interest, can you point me to any GUI bindings or native Go GUI toolkits etc.? I would like to take a look, as I am normally writing native C++ GUI desktop apps. EDIT: Thanks for all the info everyone. I hope my responses don't appear argumentative - I am genuinely curious.

0xmohit 10y ago
I haven't tried it thus far, but you can see a list at the Projects wiki [0]. [0] https://github.com/golang/go/wiki/Projects#guis-and-widget-toolkits https://github.com/golang/go/wiki/Projects#guis-and-widget-t...
Klathmon 10y ago
I'm not sure if this would work for you, but using something like Electron and having your go program output HTML/JS/CSS as your UI works really well with go (or have your go program output JSON or something to communicate with the front end) If you throw something like react on there, you'll have a pretty simple functional UI, but if you don't want that there's nothing wrong with HTML/CSS and as little JS as you can get away with.
- 72deluxe 10y ago
  That sounds an interesting concept and useful for creating instantly-usable web apps but in effect isn't your Go app being relegated to a HTTP server? eg. how would I do callbacks without doing them as some request back to the Go "server" app? How would you create custom controls in this method? eg. if I wanted to do my own pie chart control/widget with popups etc. It sounds like a long way around in comparison to what you can do in C/C++, ie native calls depending on the platform, or use an abstraction toolkit like wxWidgets. (Oddly C++ has done well without any native GUI toolkit of course, but at least there was native C ones to use).
  - Klathmon 10y ago
    Ideally you would put as much of the "business logic" in the go code as possible, and have it "render" to something like JSON which the front end just reads in and displays. Interactions with the front-end just send a new request to the go code to handle and respond with what is needed. It is a lot more work for small applications compared to something like wxWidgets, but for larger applications the decoupling of the front end from the "back end" can help in a bunch of ways. It lets you develop them somewhat separately, it gives you a uniform look-and-feel across platforms (could be a pro or a con depending on how you feel about it), and allows you to do something like replace the web-front-end with a native system later if you want (and you could write the front-end in the platform's native GUI widget library for best performance and integration while keeping the backend code identical). So your go code is basically an HTTP server at that point, but it frees you up to let go do what it does best without worrying about how you will display it, and it lets javascript/html/css do what it does best (display stuff). I've had great success doing this once before, and if you have some experience with React, it works out really "beautifully" as the front-end can be completely stateless. So what was pushed to it from go is what is displayed. Easy to test, easy to develop, and easy to replace if needed.
  - pjmlp 10y ago
    > Oddly C++ has done well without any native GUI toolkit of course, Well from the OS vendors themselves we had MFC/WTL/Windows Forms/WTL on Windows, BeOS GUI, Symbian UI, CSet++ on OS/2, PowerPlant on Mac. Additionally there was Turbo Vision on MS-DOS, OWL, VCL for Windows, Motif++ on UNIX.
dilap 10y ago
I love Go and think it could be good in this area, but so far as I know no one is using it for any serious GUI work (yet?).
- 72deluxe 10y ago
  What is it being used for? HTTP servers? 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere?
  - vram22 10y ago
    >What is it being used for? HTTP servers? Yes, that is one big area - networked servers - a superset of HTTP servers. The Google site that serves the Chrome browser is supposed to be a Go app, and I've read Google uses Go a lot internally. (I'm sure Rob Pike and his team must be using it, after developing it for that very purpose.) Reading up on the goals of Go will give some insight into that. Part of the reason was that they wanted it to write big systems at Google, including networked ones, and wanted a better experience than they had with C++ (build times [1] and also other issues). Rob Pike has written some about it, others may have too). [1] This video that I blogged about: Video: C++, Rust, D and Go: Panel at LangNext '14: http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-panel-at-langnext.html http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-pane... has many interesting language-related discussions; one of them is the discussion about the build times of C++ vs. those of more modern language. There are concrete reasons why C++ build times are relatively so large - the use of include files is part of the reason - those are discussed some in the video, between the panelists, including some of the language (co-)inventors, such as C++'s Bjarne Stroustrup, Go's Rob Pike and D's Walter Bright. There is a nice moment or two near the end where Stroustrup responds about C++ build times - okay, won't spoil it for you and others - go see it :) Command-line tools is another area where Go is used a lot. Getting the convenience of deploying a simple single binary (maybe at the most a config file or two with it) even by just copying to the deploy target - unlike what you have to do with interpreted languages like Python and Ruby (unless you use something like PyInstaller or py2exe for Python, but that is not officially supported and may or not work for all Python apps [2]). This gives us back some of the convenience of older compiled languages like C where this was the normal way of deploying - but with some benefits over languages such as C (see Go vs. C topics), plus goroutines, channels, etc., I guess. Though I have not come across any examples of what things command line apps using goroutines and channels could be used for - it would be interesting to hear/read about some. I mean apart from a few somewhat obvious ones such as a web client to download multiple URLs in different goroutines, concurrently. [2] I've tried out PyInstaller on a few Python apps, including command-line apps, and a simple wxPython app or two - it did work okay for those, in the limited testing I did. Edit: fixed typos, added a few points.
gribbly 10y ago
I'm certain there are more, but here are a few platform native https://github.com/andlabs/ui https://github.com/andlabs/ui gtk http://mattn.github.io/go-gtk/ http://mattn.github.io/go-gtk/ qt https://github.com/therecipe/qt https://github.com/therecipe/qt qml https://github.com/go-qml/qml https://github.com/go-qml/qml shiny (still being developed, Go native) https://github.com/golang/exp/tree/master/shiny https://github.com/golang/exp/tree/master/shiny
vram22 10y ago
Here is one - WALK: https://github.com/lxn/walk https://github.com/lxn/walk A friend had used it in a commercial project, and IIRC he said it worked okay. Not tried it myself yet. I think it wraps the Win32 GUI SDK but also has a declarative mode [1] (at least for GUI widget layout) on top, or something like that - only looked at some sample code briefly. [1] meaning you can declare your GUI layout declaratively, but in Go code - it does not need XML or some other language or markup format like some declarative approaches do - IIRC. I actually wish the Go team had built support for some / many of the major GUI toolkits on major OS's (at least) from near the start of Go's development. I realize that there could have been, or still could be, some issues with that, due to differences between Go and (C and C++) [2] models (object file format, calling conventions, stack and heap layout, etc. - basically compiler and compiler-output-related stuff), and hence it may not be easy to create bindings from the former to the latter. Not familiar with this area. [2] since many of the major GUI toolkits are natively written in C or C++, so a Go wrapper would need to bind to them. Not complaining though, I know what they (the Go team and community) have already done is a huge achievement anyway.

wyager 10y ago

How is Go safer than, say, Java? It doesn't really do anything particularly useful or interesting on the safety front; it's type system is weak, it has null pointers, its error management mechanisms are mediocre.

weberc2 10y ago
It's not safer than Java. The selling point over Java is developer friendliness (simpler language, tooling, dependency management, deployment, etc).
- tigershark 10y ago
  no. I really don't like java, but you really can't tell that go has better tooling and it is more developer friendly. it's an outright lie. java tooling is very mature and has solutions that no other language that I know can use. (Spock framework above all, it is written in groovy but it is perfectly integrated in java and still I haven't find anything nearly comparable in any other language). show me some BDD framework in go, just as an example.
  - vorg 10y ago
    > Spock framework above all, it is written in groovy You're the one who's telling an "outright lie" (as you put it). I just downloaded and unzipped Spock from Github, and looked through its directory structure. Virtually all of it is written in Java, not Apache Groovy. There's only a few little files written in Groovy. Perhaps you're confusing its source language with the language users of Spock write their test scripts in. In real life, Groovy is used for the JVM in the same way Bash is used for Linux, like writing glue code and build files. The statically typed stuff added in Groovy 2.x isn't used much at all, and virtually no-one would use Groovy to build actual systems. All software I know of that provides Groovy to users, like Grails, Gradle, and Spock, is itself written in Java.
- wyager 10y ago
  I was asking the GP why he cited safety as a feature of Go. I agree with you; that's not a good argument.

AsyncAwait 10y ago

> strikes the right balance for me between productivity and safety. Would be curious to hear what "safety" you're referring to, is it just that it has a basic static type system, (which is constantly being undermined by interface{} and reflection), or is there more to it? Genuinely curious.

chmike 10y ago
Compared to C it is safer. I never saw a segmentation fault, only some panic errors with bound checking. I prefer go to python or javascipt. It's far too easy to make errors in them. Minimal static code checking.
- AsyncAwait 10y ago
  > compared to C it is safer. I never saw a segmentation fault Well, yeah, it has a GC so it kind of gets that "automatically", I was thinking more about the type system side of things. And compared to C almost anything is indeed safer. > I prefer go to python or javascipt. It's far too easy to make errors in them. That's fair, but these are both dynamic languages, so almost anything with any level of static typing beats them in this regard, I was interested if Go does anything beyond that. Not to say these are not fair points, but nothing a whole host of other languages haven't provided before Go.
  - chmike 10y ago
    Not only static typing. I just found a bug in an open source python tool that crashed because of a missing member variable in a class. You have to assign a value in the attribute to create it. It requires careful programming to not get such errors. It is also easy to accidentaly create a member variable. The time you gain by being able to hack some code together is lost by these types of error unless you are a very disciplined programmer. Another kind of error with python is with blocks defined by vertical alignment. It is easy to make errors when you copy past code and the alignment is not corrected. When you are under pressure or tired, your discipline may weaken. And this is difficult for inexperienced programmers. You don't have these problems with go and the normalized formating helps a lot.