Go is still not good

Re:Go is still not good by bitdeep on Friday August 22, 2025 @03:50PM (#44989021)

- I’ve seen a lot of debate here comparing Go’s issues (like nil handling or error scoping) to Rust’s strengths.

- As someone who’s worked with C/C++ and Fortran, I think all these languages have their own challenges—Go’s simplicity trades off against Rust’s safety guarantees, for example.

- Could someone share a real-world example where Go’s design caused a production issue that Rust or another language would’ve avoided?

- I’m curious how these trade-offs play out in practice.

Sorry, I don't do Go/Rust coding, still on C/C++/Fotran.

[ Parent | on HN ]

Re:Go is still not good by metaltyphoon on Friday August 22, 2025 @04:57PM (#44989722)

> Go’s design caused a production issue

A simple one, if you create two separate library in Go and try to link with an application, you will have a terrible time.

I've ran into this same issue: https://github.com/golang/go/issues/65050

https://www.youtube.com/watch?v=xuv9A7CJF54&t=440s

[ Parent | on HN ]

Re:Go is still not good by pensatoio on Friday August 22, 2025 @09:16PM (#44992018)

> caused a production issue

that's not a production issue, and it's a very niche use case

[ Parent | on HN ]

Re:Go is still not good by metaltyphoon on Friday August 22, 2025 @09:47PM (#44992230)

It's a niche use case to have software that load plugins and it just so happens those plugins are written in Go? No it's not a niche case. If all programing you do in Go is web servers than sure you won't see this.

[ Parent | on HN ]