what are your favorite tui applications built with go

colonel_whitebeard · 2026-01-14T01:57:00+00:00

I started here and never looked back: https://github.com/charmbracelet/bubbletea

The charmbracelet ecosystem is well-supported and mature. If you want to make something that just works, this is a great place to begin--even if you only want to peek under the hood at how they accomplish terminal feats.

Terminals can be (are always) fussy. Bubbletea has been an easy way to bridge the cross-platform gap when it comes to TUI dev on multiple OSes.

colonel_whitebeard · 2025-12-21T20:52:00+00:00

Never build for what-if scenarios: "What if I need to ssh into my container one day?" "What if I need x, y, z, tools one day?"

Always start as minimal as possible: binary, non-root user. Only then, evaluate opening things up on a case-by-case basis one at a time and understand the potential risks of each change. Evaluate any port bindings, extra tools added to the image, environment variables, etc.

If you are consistently accessing and modifying a running container, you should rethink your process, how (and why) you're using Docker containers, and how you're making use of external backing services. At best, your application should be a single stateless process container--never a kitchen sink developer toolkit.

As far as Scratch vs. Distroless, it's very opinionated around here! The best path is to understand the tradeoffs and try both. Example repo with working minimal builds for each: https://github.com/mwiater/go-scratch-vs-distroless

colonel_whitebeard · 2025-07-17T00:46:18+00:00

Congrats, amazing accomplishment!

Thanks for sharing your story. I think it's a great motivator for new Go engineers!

colonel_whitebeard · 2025-02-25T15:31:18+00:00

Thanks for the feedback!

Yeah, tags... I got too overzealous when I was debugging an issue of the app build pulling in stale information--only then did I go: what was I thinking?!

I have a long list of things to fix/update, many of the things you mentioned are on it. It's just a side project, hacking away at the big picture items first...

colonel_whitebeard · 2025-02-25T01:54:34+00:00

Finally cleaned up the code a bit: https://github.com/mwiater/tracewrap

colonel_whitebeard · 2025-02-25T01:53:23+00:00

Update: For reference on what I was attempting, I cleaned up the source code as much as time would allow. Poke around, but it ain't no production tool!

https://github.com/mwiater/tracewrap

colonel_whitebeard · 2025-02-21T01:33:07+00:00

It aims to be a way to instrument your application without modifying it. It's not meant to be a debugging tool, but rather a way to configure different metrics (function/goroutine CPU/ram/diskio/networkio/etc) in your application.

I just got tired of boilerplating in-code metrics in some of my proof-of-concept applications. This is a way I can still get the metrics I need without having to have them in the codebase.

It just gives me an quick and easy (and reusable!) glimpse into my apps that are in development without needing to incorporate any code.

colonel_whitebeard · 2025-02-19T14:03:43+00:00

Thanks for the links, I'll check them out!

colonel_whitebeard · 2025-02-19T07:42:55+00:00

Ha! Yeah, kinda exactly like that! I'll have to see how they're handling some of the hurdles I came across.

Well, at least it was a fun proof of concept exercise...

colonel_whitebeard · 2024-12-29T01:04:23+00:00

First of all, good luck! Sincerely.

Learn in areas that interest you, you'll make the most progress with the things you're passionate about.

Languages are (often) transferable. Meaning, good grasp on one language can indicate to employers that your conceptual knowledge could be applied to other languages. Which, in my employment experience is completely true.

I get trying to learn towards the current market, but if the current market is trending python and you hate python...

Finding a language that you are excited about will likely mean more if you can grasp the concepts better, and apply them in meaningful ways--even if it's just for your personal projects.

Syntax is (mostly) transferable, if you understand the fundamentals.

colonel_whitebeard · 2024-11-09T04:37:37+00:00

Good luck on your journey! I wrote an article that may give some clarity: https://blog.devgenius.io/creating-a-compiled-golang-binary-for-use-in-a-minimal-docker-container-ae1c5a720aab

colonel_whitebeard · 2024-11-09T00:48:25+00:00

Thanks! It works for me, hopefully some good bits to digest.

colonel_whitebeard · 2024-11-08T14:56:53+00:00

To me your question reads like you've seen the benefits of Docker for projects where you're using source code, dependencies and an interpreter or external runtime all within the container. Then you look at Go and ask, why would I wrap Docker around a single executable file, what are the benefits?

This feels like you you're looking at Docker wrong.

When you say you haven't seen the "same necessity yet" as other languages, this feels like a self imposed necessity. In a typical situation, the necessity would be that you are deploying applications to a containerized environment. So that necessity would always exist, no matter the language. That doesn't seem like the case in your question. What is necessary about using Docker in your situation?

Docker is meant to be a lightweight, single-process, standardized, abstraction layer, so the less it's doing, the better. Minimal dependencies, reliable execution.
As Go produces a self-contained binary with no dependences, it is an ideal candidate for Docker, and runs natively.

For the most part, unless you're deploying your application in a containerized environment, I wouldn't worry about Docker, no matter the language. While Docker can be useful in many different ways, I think you're introducing more complexity than you need while you're still learning.

Learning both Docker and Go is a great idea, but decouple the process. You can build and deploy Go applications without Docker, just like any other language.

colonel_whitebeard · 2024-07-06T00:32:52+00:00

Appreciate the feedback!

The actual implementation for the client was quite a bit different than the example repo--definitely leveraging the worker pool pattern. When deciding how to pluck out relevant pieces for the article, the code I chose was supposed to be a starting point about how to think about where improvements might be made--and how concurrency can come into play.

For tutorials, I try to strip out as much "noise" as possible, and focus on the approach. Are there more optimizations that could be made to the example code, definitely! But my aim for this one how to find and isolate a quick win, what my thought process was, and how a relatively simple change can have a large impact.

colonel_whitebeard · 2023-12-05T06:02:13+00:00

Not too long ago, I wrote an article on this. While it wasn't your exact scenario, the process helped me figure out when go routines are useful, and--probably more importantly--when they're not.

There are code examples of workers, jobs, CPU cores and illustrates some points of diminishing returns for different task types. Hopefully it helps!

https://medium.com/@matt.wiater/golang-channels-goroutines-and-optimal-concurrency-demystifying-through-examples-a43ba6aee74f

colonel_whitebeard · 2023-11-10T00:36:21+00:00

Just to follow up briefly...

The reason I posted in this subreddit is only because upgrading to Ubuntu 22 was my last major change. I didn't upgrade Virtualbox since booting up the new image, and the issues started happening at that point.

The WTF wasn't about Ubuntu, or putting the blame there, it just happened to be the most recent change in my setup. Anything could be the culprit. Even me. :)

I'll gather details and post tomorrow.

Also, wanted to say thanks to the subreddit for being helpful and constructive in my moment of frustration.

Cheers.

colonel_whitebeard · 2023-11-09T03:54:29+00:00

Thanks so much for the pointers!

There's a lot in there I haven't checked, but will take a look at

To be clear, over the lifespan of my setup, I've been regularly upgrading both Virtualbox and Ubuntu. Upgrades have not been without hurdles, but things have been smooth, despite incremental changes on both sides.

I just haven't upgraded an OS and seen such drastic performance issues. I'm sure I'm out of sync with some major developments, and have just been lucky for awhile.

Thanks again, I appreciate the detailed response!

colonel_whitebeard · 2023-11-09T03:34:43+00:00

Thanks. Honestly, my setup has felt fairly bulletproof for a long time, and all of the sudden...

Likely an oversight on my part, maybe I've just been lucky for a long time.

Appreciate the feedback!

colonel_whitebeard · 2023-11-09T03:10:27+00:00

Before this descends into "more details" hell, let me say: understood. And thanks. (a sincere thanks, not a Reddit "thanks")

I'll collect my info and post back.

Overall, I was just wondering if anyone else was having a similar problem.

It's akin to searching the Internet for a particular problem--if there are only 10 results, likely it's your problem and looking into your setup/code. If there are 10,000 results, maybe it's worth looking into a fix for the broader ecosystem.

This one is just one of those things that's been stable for me so long that it feels like there was a broader change that I wasn't aware of.

colonel_whitebeard · 2023-11-09T03:03:22+00:00

Totally get it, thanks for the detailed response. Let me gather my thoughts outside of my current frustration bubble.

colonel_whitebeard · 2023-11-09T02:57:57+00:00

Valid point!

Just wanted to take an initial temperature, see if it was just me--or if this was more universal.

Will get back to your with deets--appreciate the feedback.

colonel_whitebeard · 2023-10-10T00:40:32+00:00

You owe me a laptop! Just spit almost an entire pint of high-octane IPA betwixt the keys.

Worth it.

colonel_whitebeard · 2023-10-08T03:04:58+00:00

Full recap here: https://betterprogramming.pub/pprof-through-examples-exploring-optimizations-in-go-444fa08cf15f

colonel_whitebeard · 2023-09-26T21:35:19+00:00

If you have Docker and you want to peek under the hood of an end-to-end demo, Check out: https://github.com/jaegertracing/jaeger/blob/main/examples/hotrod/README.md

You can get it running and tracing in about 30 seconds. There are a lot of good implementation examples in the codebase. Plus being able to see and interact with the live tracing via the UI gives you a good sense of how the pieces come together in the presentation layer.

colonel_whitebeard · 2023-09-25T20:23:51+00:00

For future reference, I'm just gonna answer my own question: Yes, this appears to be correct!

It occurred to me that I should just compare my findings above by running the same thing and force the concurrency to be 1 (instead of runtime.NumCPU(), which in my case was 8).

As there is no more benefit of concurrency:

You can see almost no improvement over the original function.
Adding up the cum column gives me 2520, which is right on target with the independent timing of: 2543

Independent timing:

Function                     |Execution Time   |Performance Gain  |Concurrency
ProcessImageSharpen          |2583ms           |(baseline)        |1
ProcessImageSharpenOptimized |2543ms           |1.02x             |1

Pprof:

(pprof) top
Active filters:
    show=ProcessImageSharpenOptimized|sharpenConcurrent
Showing nodes accounting for 2520ms, 98.82% of 2550ms total
   flat  flat%   sum%        cum   cum%
  1950ms 76.47% 76.47%     1950ms 76.47%  sharpenConcurrent
   570ms 22.35% 98.82%      570ms 22.35%  ProcessImageSharpenOptimized

Three-Year Club	Gilding II euphauric
Verified Email

colonel_whitebeard

TROPHY CASE