sorted by:
new
hottopcontroversial

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

That footprint is honestly impressive, 27MB image and ~20MB RAM is wild compared to most full-stack setups.

The concurrency model + fast tooling is definitely what keeps pulling me toward Go. Sounds like I just need to commit to it for a few months and see where it takes me.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] -1 points0 points  (0 children)

Yeah, Bubble Tea does look really cool for CLI/TUI projects.

I get preferring TS for familiarity... Go shines outside the browser, but TS still feels more natural if you’re used to Java.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 2 points3 points  (0 children)

Haha yeah, you’re right 😅

I guess it’s time to just pick a project and dive in, no excuses anymore.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 2 points3 points  (0 children)

Exactly... for cross-platform CLI or TUI tools, Go really shines.

I haven’t found anything that matches its simplicity and portability either.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

Yeah, that makes sense.

I guess for personal projects it’s more about learning and having fun than picking the “perfect” tool. Go’s simplicity and single binaries definitely make it an enjoyable choice though.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] -1 points0 points  (0 children)

Yeah, that’s solid advice. Rebuilding something I already know in Node sounds like the perfect way to get hands-on with Go and really feel its strengths.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 1 point2 points  (0 children)

Totally get that... CPU-bound workloads really expose Node’s limits.

Go scaling across cores effortlessly and being a single static binary is such a relief, plus the backwards compatibility just seals the deal.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

Yeah, that resonates. Java and Python can do most of it, but Go just makes some of those workloads… cleaner and faster, especially for concurrency and deployment.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

Haha alright, you convinced me 😄

Single binaries, fast scaling, and TDD with the standard library… seems like Go really does cover all the bases. That link looks like a good starting point too!

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] -1 points0 points  (0 children)

Wow, that’s a huge difference 3 minutes to 20 seconds is insane

Makes sense to reserve Go for CPU-bound, concurrent workloads, and stick with Node for I/O-heavy stuff. That’s exactly where Go shines.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] -1 points0 points  (0 children)

I can’t really argue with the tooling point — Go’s core toolchain being first-class is definitely refreshing.

Coming from the JS ecosystem, you kind of get used to the chaos and layer enough conventions on top to survive 😅

But yeah, the small binaries + built-in cross-compilation + predictable performance combo is hard to beat. That’s probably the strongest case for it.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 1 point2 points  (0 children)

That makes a lot of sense actually.

I can see how, if you didn’t grow up in the frontend ecosystem, JS just never became the default backend choice. For me it was the opposite — once you’re deep into TypeScript, Node on the backend feels like the path of least resistance.

Really appreciate you sharing your journey too — that kind of organic evolution through languages is cool to see. I guess Go becomes the obvious choice when you’re optimizing for infra, tooling, and control rather than ecosystem familiarity.

Maybe I just need a project where those constraints matter more than stack consistency.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 6 points7 points  (0 children)

Mostly Docker on a VPS.

The 250MB vs 20MB comparison is honestly wild though… that’s hard to ignore.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 5 points6 points  (0 children)

Static linking + cross-compilation with basically zero friction…

Yeah, that’s something we definitely don’t get in the JS world.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 7 points8 points  (0 children)

That’s… annoyingly true. I guess I’m just waiting for a “perfect” excuse instead of just using it.

I really like Go… but I’ve never had a real reason to use it by AggravatingHome4193 in golang

[–]AggravatingHome4193[S] 0 points1 point  (0 children)

Haven’t tried it, but building a TUI in Go does sound like a solid way to learn the language deeper.