I've been using Go for a personal project of mine recently. I had briefly used it at the tail end of my internship while getting my degree, but nothing particul

I've been using Go for a personal project of mine recently. I had briefly used it at the tail end of my internship while getting my degree, but nothing particularly in-depth, and it was some pretty simple server code that never really challenged me. There's definitely some nice stuff about it, but there's also some stuff that's a bit of a pain. For one thing, being straight up unable to compile a program if there's an unused variable, not even a debug compiler flag or anything to allow it while testing. There's a lot of cases where I just want to move one thing around, or I'm partway through writing a function and just want to see what state something is in at a point, so I want to throw a breakpoint on a line and run the program up to that point. But even though my code is technically all valid, because the variable I want to look at is unused, or I commented out a line that makes something else unused, I now can't compile at all. So there's a lot of times I'll have to throw in a random fmt.Print of a random property of index zero of an array or something, which might crash anyway if it's reached, but at least it'll compile. It maybe doesn't seem like it would be that big of a deal, but when you've got a train of thought going, and you're trying to iterate fast, it can really pull you out of the flow of things. There's also a lot of weird situations where I find it hard to keep things clean. For instance, I like using this shorthand: if err := doThing(bar); err != nil { // handle error } But if you're doing it in a case where your function returns a result and an error, i.e. if foo, err := doThing(bar); err != nil { // handle error } That's indeed valid code, but foo only exists in the scope of that error handling. So you'd have to declare it above with its type var foo FooType if foo, err := doThing(bar); err != nil { // handle error } But you can't actually do this because when using type inference, both return values have to not be declared beforehand. So you have to pull err out into a declared var with a type, and remove the type inference altogether like this var foo FooType var err Error if foo, err = doThing(bar); err != nil { // handle error } And from that point on, if you're using this pattern again anywhere else below in that function and you want to continue using that slick error handling shorthand, there's barely any point because err already exists in your scope, and you'd just be redeclaring it. Perhaps there's some tricks I don't know about, but I tend to run into situations like this a lot, and I spend so much time trying to appease weird edge-cases of the compiler's strict rules that is really throws a wrench in my workflow.