171–173 of 173 posts
Earlier quoted context omitted.
does anyone run production code with 'go run'?
depends on how you view/classify production, sometimes yes I do! if I refactor some too complicated bash script into a script.go file and then execute it against production DBs/APIs with a `go run`.
"go run" was a great way to run go code as scripts. But maybe it is not now. Why? because Go 1.22 introduced a change that breaks backwards compatibility (changing the semantics of "for;;" loops). Without language version specified (such as in go.mod files), the change will often cause unintended damage.
It's quite rare to find any Go repos without go.mod nowadays. So what's the problem again?
But anyway, just being rare, so deserves to be ignored?
Earlier quoted context omitted.
Go makes error handling explcit, which is a very important part of development. Not only this makes you more conscious on thinking what you need to do when something goes wrong, but also makes codes more maintainable in my opinion. I strongly prefer go error handling compared to a throws-type-error-handling language. Also, with this comment I hope to get some pushback: I haven't kept up with the latest typescript, py…
> Also, with this comment I hope to get some pushback More of a push forward, really: if error-handling guarantees are what's driving you away from dynamically typed langauges, Go is pretty much the worst place you can land that isn't C. It doesn't make you check nils, it doesn't remind you to check error values from functions that you call only for side effects (though the linter will, admittedly), and it doesn't ha…
I'd love to have the chance to explore the nuance of what other tradeoffs include going with any other language, but certainly requires more nuance than a deep comment response might trigger.
But just trying my luck, what do you think is worth trading off the more exhaustive error handling? (Regardless on dynamically typed or not)