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.
I prefer go to python or javascipt. It's far too easy to make errors in them. Minimal static code checking.
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.
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.
Better comparison is to compare Go to Java, also doesn't segfault, because it doesn't let you.
https://en.wikipedia.org/wiki/Memory_safety
https://en.wikipedia.org/wiki/Type_safety
http://tobyho.com/2008/03/30/how-safe-is-your-programming/
The fact that people consider "security releases" for compilers/runtimes to be normal and acceptable is actually extremely alarming to me, but it's different from language safety.
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.
EDIT: Thanks for all the info everyone. I hope my responses don't appear argumentative - I am genuinely curious.
[0] https://github.com/golang/go/wiki/Projects#guis-and-widget-t...
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.
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).
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.
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.
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-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.
> 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere?
You could apply this criticism to nearly all languags, as there are currently only very few that are used for native GUIs: C and C++, because the operating systems and native toolkits are written in that, C# for Windows (Winforms and WPF) and Java for cross-plattform GUI applications.
there's some python stuff. the original bittorrent client. i did a couple apps using PyQt and python -- not an experience i would want to repeat, though.
For others maybe Delphi was succesful in the GUI domain. But in the last years it was certainly not often mentioned. For GTK there's also Vala, which was probably even designed to be used for GUIs.
Objc is certainly C-derived, but it's also just as much smalltalk-derived. Definitely a very different beast than plain C (more so even than C++, I would say).
platform native https://github.com/andlabs/ui
gtk http://mattn.github.io/go-gtk/
qt https://github.com/therecipe/qt
qml https://github.com/go-qml/qml
shiny (still being developed, Go native) https://github.com/golang/exp/tree/master/shiny
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.