31–40 of 58 posts
Hmm, does the name "GTK" mean "Gnu Tk"? I thought this was "Go Tk" for a moment when I read the title.
Are 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.
Are 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.
How is this different than this? https://github.com/norisatir/go-gtk3 They also set finalizers.
I just gave it a try now, but the code will not compile on my dev box (OpenBSD, go tip). Even after making some minor fixes (I fixed an #include directive, removed a call to a deprecated function, etc.) there appear to be some serious issues (one error I got mentioned the size of an array being negative).
It appears this code has not been updated in a year, and we wished to target a recent GTK version (3.8, to be precise) with our bindings. Had we known about the project, we probably would have considered submitted patches to fix its issue and bring it up to date with newer dependencies, but even then, I feel that it would be almost as much or perhaps even more to fix and verify an unfamiliar and broken code base than rolling our own.
But I'm glad to see this project seems to be doing memory management in a Go-like manner.
Are 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.
However, even ignoring the CGO-based frameworks, there's nothing wrong with mostly using Go as if it were C with closures (and garbage collection, and interfaces, and optional implicit typing and reflection), that's how most Go code looks, even in the standard library. Channels/CSP are great if you need to easily pass data among concurrent goroutines, but not all code neatly fits into that model nor benefits from concurrent execution.
One of the early mistakes most newbie Go programmers make (and I did this myself as well) is overusing channels, just because "hey, channels are super cool"!
Are 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.
How is this different than this? https://github.com/norisatir/go-gtk3 They also set finalizers.
In short, we weren't aware of the project. I just gave it a try now, but the code will not compile on my dev box (OpenBSD, go tip). Even after making some minor fixes (I fixed an #include directive, removed a call to a deprecated function, etc.) there appear to be some serious issues (one error I got mentioned the size of an array being negative). It appears this code has not been updated in a year, and we wished to…
It is a little frustrating as it is one of the first projects that comes up when searching for "go" and "gtk3" on Google. So, it is is an alternative to what you are doing I guess.
Slightly off topic, but something I've been curious about. Go decided on garbage collection to manage memory. Why do so few languages offer something like C++'s RAII?[1] In C++, when you define a class, you define the constructor(s) and the destructor. Then the destructor is called whenever the object goes out of scope. Easy. This is the gist of RAII. Furthermore, in C++, a default destructor is automatically generat…
Preferring RAII over garbage collection is the decision that Rust made. Probably the reason that more languages don't use RAII for memory management is safety. C++, even with RAII, is not safe—you can violate memory safety with certain uses of references and iterators. Rust has to go to great lengths (lifetimes and the borrow check—things that have only been in the research landscape) to make this safe.
Unfortunately for me, the rust compiler is written in rust, so I would have to adventure to grab a Linux and try my hand at a cross compile before I can play with it on my OpenBSD box.
Slightly off topic, but something I've been curious about. Go decided on garbage collection to manage memory. Why do so few languages offer something like C++'s RAII?[1] In C++, when you define a class, you define the constructor(s) and the destructor. Then the destructor is called whenever the object goes out of scope. Easy. This is the gist of RAII. Furthermore, in C++, a default destructor is automatically generat…
This approach starts getting brittle when you get into objects that aren't procedure-scoped; for instance, a global session table in a web application, or a request token tracker in an RPC system. These are also the kinds of object lifecycles that tend to be behind leaks and corruption in programs that don't use RAII. People use shared pointers to mitigate that problem, but shared pointers are (a) a reference countin…