How is this different than this?
https://github.com/norisatir/go-gtk3
They also set finalizers.
Gotk3: GTK3 the Go way
21–30 of 58 posts
Re: Gotk3: GTK3 the Go way
#22Earlier quoted context omitted.
It's more error prone than GC and there aren't really enough advantages to RAII to make it worth it much of the time. Sometimes, sure, but GC is nicer and usually fits the bill.
How is it more error prone than GC?
It leaves more in the hands of the developer (some would call this "power"), which presents opportunity for programmer error.
Re: Gotk3: GTK3 the Go way
#23Earlier quoted context omitted.
How is it more error prone than GC?
It leaves more in the hands of the developer (some would call this "power"), which presents opportunity for programmer error.
A safe RAII system based on unique types is precisely, by definition less powerful than GC, because it allows no operations that GC doesn't allow but forbids some operations that GC allows (namely aliasing).
If you're talking about C++'s unsafe implementation of RAII, that's true of course.
Re: Gotk3: GTK3 the Go way
#24Earlier quoted context omitted.
If you want the latest Go version on Ubuntu : http://blog.labix.org/2013/06/15/in-flight-deb-packages-of-g...
You can also just build tip on your own locally. Go has virtually no hard dependencies other than gcc (and mercurial to get the repo, unless you pull the code some other way). hg clone http://code.google.com/p/go cd go/src ./make.bash (or ./all.bash if you want to run all the unit tests) Same holds true even on Windows if you have a local gcc like MinGW (the only notable difference is you'll execute make.bat instead…
Google also distributes binaries for Linux, for me all I do is unzip the file and set up my .profile to look for go in the path it was exported in..I set this up on a per-user basis but it works fine for me.
Re: Gotk3: GTK3 the Go way
#25Earlier quoted context omitted.
It leaves more in the hands of the developer (some would call this "power"), which presents opportunity for programmer error.
A safe RAII system based on unique types is precisely, by definition less powerful than GC, because it allows no operations that GC doesn't allow but forbids some operations that GC allows (namely aliasing). If you're talking about C++'s unsafe implementation of RAII, that's true of course.
C++ is in fact where my experience with RAII comes from. Could you, for example, forget to make a destructor virtual in "safe" implementations of RAII?
Perhaps the real answer to "Why isn't RAII more popular?" is that C++ has poisoned the well for many programmers.
Re: Gotk3: GTK3 the Go way
#26Earlier quoted context omitted.
A safe RAII system based on unique types is precisely, by definition less powerful than GC, because it allows no operations that GC doesn't allow but forbids some operations that GC allows (namely aliasing). If you're talking about C++'s unsafe implementation of RAII, that's true of course.
C++ is in fact where my experience with RAII comes from. Could you, for example, forget to make a destructor virtual in "safe" implementations of RAII? Perhaps the real answer to "Why isn't RAII more popular?" is that C++ has poisoned the well for many programmers.
> C++ is in fact where my experience with RAII comes from. Could you, for example, forget to make a destructor virtual in "safe" implementations of RAII?
No, that would be unsound.
> Perhaps the real answer to "Why isn't RAII more popular?" is that C++ has poisoned the well for many programmers.
Totally agreed. (But that said, I think that Go, and most other languages, made the right decision when going with pervasive GC. It makes the language much simpler, both in terms of implementation and interface. It costs some performance, of course, but being as fast as C in all cases was never a design goal of Go, according to the FAQ. The complexity, both in interface and implementation, that languages buy into if they want safe manual RAII-style memory management is not trivial.)
Re: Gotk3: GTK3 the Go way
#27Glad to see some more work being done on UI frameworks in Go, though I doubt this will end the splintered nature of all the different (mostly half-baked, honestly) options.
I've personally been using a Qt5.1/QML based solution with a Go/CGO based QML plugin that acts as a bridge between QML and backend Go code. It doesn't try to export much of Qt to Go, it basically expects you to write the UI logic in QML/QtQuick and then just use Go for the underlying app logic, using the QML plugin bridge to allow Go code to call QML functions and vice-versa. In practice this works somewhat like writing a Go server that manages an HTML UI for doing browser-based UIs with a web-based RPC system, except I can write the UI code in QML which I find much preferable to HTML/JavaScript (variable binding Just Works, no need for frameworks like Angular, no need to mess with CSS, can efficiently pass around binary data in byte arrays easily, etc).
Currently my solution isn't even half-baked, I've been implementing it to serve a specific app, and it currently has some dependencies that force it to be Windows only (these could be trivially removed, but doing so isn't important for my app). I may share the code for this sometime in the future after it has matured a bit more, though there's really not that much to it.
Re: Gotk3: GTK3 the Go way
#28Hmm, does the name "GTK" mean "Gnu Tk"? I thought this was "Go Tk" for a moment when I read the title.
gnome tool kit. Note that gnome is pronounced gi'nome just like gnu is pronounced gi'new.
Re: Gotk3: GTK3 the Go way
#29Re: Gotk3: GTK3 the Go way
#30Are channels and CSP failing as the favored design approach? I keep seeing frameworks that just seem to use Go as if it were C with closures.