Yeah this gentleman is Jan Mercl and is quite known in the Go community. I think his most known project is the sqlite driver in pure Go, as opposed to mattn's driver.
As someone who doesn’t know a lot about go: why is CGo-free a feature? In what situations is CGo (which is basically just calling C libs from go, right?) bad?
It makes cross-compiling a lot more difficult. Instead of being able to build on whatever OS/architecture you use and produce binaries for any other OS/architecture you want to target with a single command (one of Go's superpowers), you need a complex build pipeline.
I've been using zig's toolchain in CGo projects for a couple years now and cross compilation _just works_. Maybe there are libraries it doesn't handle well but so far all of my use cases have been covered perfectly.
Note that modernc/cznic stuff is not really actual go but C trans-compiled to Go, the trans-compiler having specific quirks for every platform,.
So it's not technically possible to compile to all platforms that Go runs on, only the platforms that the trans-compiler supports. And the resulting Go code is not that readable.
But it still improves cross-compiling, and results in a libc independent static binary, which is nice. And the work done on the trans-compiling is great.
FFI is an additional headache. Instead of having a single hermetic build process that just works, with FFI you now have to deal with shared libraries which may or may not be present, and may or may not support all the architectures or operating systems you want to target. FFI is why so many Python projects blow up when you run pip install. Then it takes sometimes hours to untangle that horror show.
This is using purego which is still using FFI, it is dynamically linking the C libs so you still have the same shared library issues. You don’t have to setup a C compiler toolchain though which is nice.
I mean why don't they do it for the source library too? There are very few operations in C that can't be done in Go (mostly inline assembly and some pointer manipulation) under a standard userland assumption.
Cgo is the correct choice for many domains (ui, gamedev, systems stuff) where you can’t use a network boundary as your “interacts with other languages”.
The language is opinionated; it’s not good at playing with others. It’s good at other things (network services, etc)… but you can and it’s not bad.
…it’s just hard, and people don’t like hard things.
That library (like this) claim “no cgo” when they use ffi is just ridiculous.
This one is particularly egregious in even supporting cgo!
Pure go my ass. You’re invoking c functions. It’s not pure go.
The distinction is in the tool chain; cgo is a better, first party solution.
Purego is an unstable (it is, read the repo!) workaround for people who a) don’t like the word “cgo” or b) dont like having a c tool chain.
…but realistically you have to interop with c code in many domains.
Sure, a pure world is great, but that’s not always possible.
People who don’t like cgo and choose purego are doing it for, mostly, optics (cgo is bad! This isn’t cgo… it’s ffi… totally different) and appear to fail to appreciate the technical distinction more complicated than they imagine, and they are still using c.
Being CGo-free is very desirable when you can't/don't want/don't bother to link C library deps for some reason. On example when you don't want to do that is cross-compiling for another architecture and not really being able to control what runtime libraries are installed on the target.
So, it simplifies build pipelines, at the cost of being a bit slower in the runtime.
IIRC they were called tear-off menus in X / Motif days.
I had attended a company course on X Windows, Xlib, and Motif programming, back in the day.
Motif might have been clunky or whatever, but was also powerful. That course was my first introduction to event-driven GUI programming and I was quite junior then, and didn't quite grok all the programming concepts involved, but a colleague, who was more knowledgeable, created a rudimentary MS Paint-like application, in about 1 hour or less, using Motif and C.
(Okay, he worked in the same company as me, but in a different city, so might have had the hardware and software resources to practice on X and Motif before the course, which I did not have.)
The application menus (like File, Edit, etc) had a built-in way of detaching them when they were expanded so that you could keep them open and place them somewhere convenient on your screen. This was useful if you had to select different menu options frequently.
It's too ugly for "general-purpose" apps, but it looks to be perfect for internal management apps (control panels, tools). I'm definitely going to try it for my key-management server.
I do not see anything particularly ugly in provided screenshots. And many "modern" utterly unergonomic applications with lots of wasted whitespace, low contrast invisible text and "clickable" elements that look the same as the rest are pure abomination. But I guess it can be a generational difference.
How does this avoid Cgo? In the case of Ltk (FFI-free, Common Lisp bindings for Tcl/Tk), I know that the library communicates strings to a Tcl interpreter. This means no FFI is involved, but it does mean the user must have Tcl -- specifically, wish -- installed. Is there a similar requirement for this library?
Unfortunately, GitLab is locked behind Cloudflare turnstile and I can't access the source code.
I'm really impressed that it can render math from TeX input. Is this a common thing in GUI toolkits? My graphics experience is mostly limited to Java's Swing and OpenGL from my college days.
Apparently it's embedding actual TeX for this purpose: https://git.sr.ht/~sbinet/star-tex (TeX is written in a Pascal variant, and this kind of transpilation is by no means unusual.)
It's common to have HTML widgets in GUI toolkits, and some may even support MathML, but this here is a bit different.
How I wish andlibs/ui (actually native widgets) wasn’t abandoned in a half-done state. Now to build any GUI in Go that doesn’t look abominable I have to use Wails, this is no exception.
Hm... the examples look nice, but there are several examples that render graphics and/or text on a canvas. How about demonstrating more complex controls, e. g. list views?
It is cgo-free, but it seems to require several libraries. I am concerned that some people may misunderstand that it can be run as a single static binary.
These are Go bindings for Tk, a cross-platform widget toolkit initially developed as extension for Tcl. Nowadays a lot of languages have bindings for Tcl/Tk. Python for example has been including tkinter [0] for a long time.
Seems Tk is now the default cross platform UI for any language. It is doing for local apps what JavaScript has not - a usable toolset for majority of use cases without a ton of overhead and interference. I e only played with tcl/tk over the years - now will put in some hard yards to try in depth. Golang+tk for heavy lifting and server side and tcl/tk for scripts and as hoc things. After 50 years of casual/prof development this might be my personal version of nirvana. YMMV.
Really? Would love to see a binding for Powershell. Just for cross-platform shell scripts to be able to disable a pop-up for input etc. Just makes them more accessible.
Figma killed the desktop app. I yearn for the good old days of standardized UI if I actually need to get shit done efficiently. Nowadays it's learning everything from either scratch; maybe if you're lucky, the designer put in some 'intuitive' (read 'fashionable') interactions.
You write like you were born after all the events related to the desktop application had run their curse.
We killed the desktop app, to free ourselves from the Wintel monopoly. We pushed the migration to the Web, because that was the unreachable niche for Microsoft and their monopolistic practices.
We succeeded, and as punishment, now we have to endure all these applications written in Node.js with Electron UIs. We won, but we have paid a high price for it.
In this context, Figma is nothing more than an afterthought. Something that appeared as a consequence, not the cause of anything.
And I may add that even Microsoft themselves killed desktop apps.
I mean, just try creating a GUI app even exclusively for Windows in 2024 : it was their strength in the past, it’s now the same pain as everywhere else.
Even Windows 11 uses multiple intricate UI frameworks from Microsoft, sometimes on the same screen without any UI coherence.
>You write like you were born after all the events related to the desktop application had run their curse.
>We killed the desktop app, to free ourselves from the Wintel monopoly.
Bombastic nonsensical crap!
There is no "we”, period.
That is a fallacy that you, not "we", impose upon yourself, and try to generalize it to, or foist it upon, everyone.
"We" didn't kill anything. and "we" were not slaves in the first place, so "we" didn't need to make ourselves free.
Maybe you, and some known to you, were slaves, or still are. Don't generalize vacuously.
This is not the multiple Oscar-winning award-winning Ben-Hur movie or the Biblical story of the ancient Israelites as slaves in Egypt or something like that.
Anyone, who wanted to, or at least, any reasonably large group of people (1), could have moved off, from Windows, if they wanted to, badly enough. In the early years of Windows, DOS was still there, right? And had plenty of good software on it, just not GUI-based. and there were some Unix versions around, including maybe some cheaper ones. I rememember Coherent Unix and ESIX, for example. I actually work on the latter, briefly, in an early job. Microsoft's own Xenix existed around the same time too, plus or minus a year or three, maybe.
(1) Say a few hundred or a few thousand people. As an example, they could have collected donations, and hired 20 to 50 smart computer science students, grad or undergrad, and / or professors and / or operating system developers, to create a better OS without the monopoly and bad practices of MS. You bet your ass, at least some people would have queued up for that.
Set up some rules for correct behaviour, and kick out anybody who did not comply.
>We pushed the migration to the Web, because that was the unreachable niche for Microsoft and their monopolistic practices.
So, your only option is to run away from an enemy? And do you think that the enemy cannot follow you there? What about WSL and Azure and what not? Ha ha. Never underestimate your enemies.
See the Stockdale Paradox. The Jim Collins version is a good one.
Now it looks like a wonderful alternative to all the bloated, wasteful, Electron JS applications out there.
reply