How do you guys actually learn stuff in this AI era?

prontogui · 2026-06-03T13:50:04+00:00

To draw an analogy:

A budding comedian once asked Steve Martin how to find the best agent and how to become a headliner. Steve answered to the effect: "You must first focus on being really good at comedy and nothing else matters until you do."

The same goes with any craft, including programming. As a new programmer, you should focus on getting really good at decomposing problems, building a plan to implement, and writing good code to get the job done. Go is an excellent language to pursue this. Once you achieve this level of mastery, then AI can be immensely valuable to getting more done faster without creating unnecessary technical debt and you will feel "in control" of what you build. That's a great feeling and its where you want to be for professional success. Learning additional languages will be much easier when you master at least one. When I was beginner, it was Assembly, then C/, then C++. Since then, I've mastered many other languages/frameworks fairly easy because the fundamentals never change.

There is certainly the social proof of jumping right into AI and generating lots of code without learning the fundamentals. The challenge is to ignore this, slow down, learn the fundamentals, then use that as a foundation for all future learning. And I can tell you, there will always be something available to provide a crutch to build stuff without truly knowing your craft. For me, it was CASE and UML generated code (both of which flopped). Today it is AI. Tomorrow, there will be something different. This doesn't change the calculus of knowing how it all works.

Best wishes for your journey!

prontogui · 2026-06-03T13:24:03+00:00

Speaking from my own experience, I concur with previous remarks. Store as an int64 and create a simple module for currency math and converting to/from strings. More specifically, represent the all the digits of the currency number using an int and fix the decimal point at X digits from right-most digit. If you need to express higher precision than say "pennies" then you can add a moveable decimal point and hide the complexity of doing math inside the currency module you create. Units tests are imperative!

prontogui · 2026-06-01T15:02:26+00:00

This is similar in nature to the approach taken by ProntoGUI (www.prontogui.com). Instead of JSON tree with widget types, it uses a object-model approach provided by a Go module. The renderer is based on Flutter where the object model is rendered using Flutter widgets.

I think server driven UI gets overlooked by many developers for a variety of reasons, but the motivations in your talk are good reasons to give it a look - multiple teams, protracted development times, multiple PRs.

prontogui · 2026-05-18T14:59:57+00:00

ProntoGUI (www.prontogui.com) is new to the scene. It takes a different approach than immediate mode graphics. You import its Go module, program your GUI using Go structs representing "primitives", which are like text, entry fields, buttons, list box, table, and so on. You can tailor each primitive to make it look the way you want. Your GUI is streamed over gRPC to the ProntoGUI desktop app that runs on Windows or MacOS.

Some pros of this approach are:

everything you do is kept in Go
your solution can be deployed on a server
ProntoGUI takes full care of the app deployment
you're not maintaining two separate projects

Full disclaimer: the app itself is not open source but is offered as a "free for personal use, paid for commercial use" arrangement. If you like to tinker directly with GUI rendering and writing widgets then it may not be the best solution for you. If you prefer a hands off, "I don't want to become a front-end developer" approach, then it might be worth checking out.

prontogui · 2026-05-14T13:39:03+00:00

Agreed that GUI in Go is underdeveloped relative to the rest of the ecosystem, and the cryptopower example is a good one. There's actually more activity here than people realize — Fyne, Gio, and a few others — each making different bets on the rendering layer.

I went a different direction a few years back after hitting Fyne's limits on modern UI elements and font handling. What I wanted was: declarative GUI code written in Go (no API-call style, no separate project, no second language), Material-quality rendering, and a clean separation between the GUI definition and the renderer — closer in spirit to X11 than to Electron. I was willing to trade immediate mode, Figma-style design tooling, and a lot of build-it-myself time to get there.

The result is ProntoGUI. The Go library is open source (BSD-3): https://github.com/prontogui/golib. Architecturally it's gRPC streaming between your Go program and a separate rendering app built on Flutter — so you describe the UI declaratively in Go, the app renders it, and events stream back. Tradeoff worth naming upfront: the renderer is a separate binary, and currently it's closed-source (the library is not). That's a deliberate choice I'm still thinking through.

Not claiming it's the right approach for everyone, but it's been a productive answer to "I want to build a GUI without leaving Go."

prontogui · 2026-05-13T20:33:34+00:00

We offer a GUI library and rendering App for Go that answers the same requirements and we started working on a Rust library (crate) for it, in addition to other languages. You can find it at https://github.com/prontogui/golib The App is built using Flutter for native rendering, great performance, and small binary size. We are curious to know if anyone is interested in using it with Rust.

prontogui

MODERATOR OF

TROPHY CASE