Thirteen Years of Go
71–80 of 217 posts
Re: Thirteen Years of Go
#72Why exactly is Go so special? For a compiled language it's not very fast and doesn't seem to be making much traction. I think people simply like it because of it's Bell Labs heritage and pretty syntax.
Re: Thirteen Years of Go
#73Earlier quoted context omitted.
By amazing do you mean specifically for Go? Because I don’t see how it differs from working on two Maven projects simultaneously in Java where one depends on the other.
In maven, don't you need to update the pom file of the projects to point to the local copy? What's nice about the Go workspace system is that the workspace lives above the individual modules, meaning that the individual modules don't need any modification to pull in local dependencies. E.g. if your workspace looks like this: workspace/ mod1/ mod2/ Then both mod1 and mod2 will pull their dependencies remotely. But if…
Yes and no. It depends. You can use modules. With modules, each sub project lives in a directory under the root project. Maven reactor figures out the build order and all that crazy stuff. It’s the same with sbt and gradle.
Re: Thirteen Years of Go
#74Earlier quoted context omitted.
Docker and corresponding tools. https://github.com/abiosoft/colima And many others, really.
> Docker and corresponding tools. https://github.com/abiosoft/colima Neither sound like "applications I really enjoy". More like applications you suffer. > And many others, really. How about examples?
Re: Thirteen Years of Go
#75Why exactly is Go so special? For a compiled language it's not very fast and doesn't seem to be making much traction. I think people simply like it because of it's Bell Labs heritage and pretty syntax.
1. wide range of OS's you can target
2. no dependency on libc, you can build and copy over a binary to a machine and it will work
3. fast compiles
4. amazing stdlib, makes writing no to low dependency code very attainable
(imo) there's very little reason to start a new backend project in ruby/python/js when you can just use go and get better performance
> doesn't seem to be making much traction
Its one of the most in demand languages, at least according to linkedin in my area.
Re: Thirteen Years of Go
#76I really want to love this language, a fast and simple garbage collected lang, but feel like they missed the spot a little. I just wish they did something different with error handling / nil, doesn't feel right for the language. Also whats up with stuff like unused imports being such a big deal?
I keep count in my own code of the number of bugs Go's "damnable use requirement" has caught for me, and I'm now up to 5. It's not a big number, but they were real bugs that would have annoyed the shit out of me if they'd made it into shipping code. I think this is one of the polarizing decisions Go made that is going to turn out to be universal orthodoxy 10 years from now. I think error handling is the thing about G…
The second problem is nil, use of which is common and doesn't enforce error handling.
Re: Thirteen Years of Go
#77Why exactly is Go so special? For a compiled language it's not very fast and doesn't seem to be making much traction. I think people simply like it because of it's Bell Labs heritage and pretty syntax.
What do you mean by this? By what metrics and what would qualify as making traction? Many companies use Go and many prominent and widely used open source projects are written in Go.
> it's Bell Labs heritage
I have never met a person (in person, offline) who has cared about this at all.
> pretty syntax
One of the most common things you hear as a knock against Go are things that explicitly do not lead to "pretty" syntax, such as its error handling.
Overall, your comment confuses me.
Re: Thirteen Years of Go
#78Why exactly is Go so special? For a compiled language it's not very fast and doesn't seem to be making much traction. I think people simply like it because of it's Bell Labs heritage and pretty syntax.
Re: Thirteen Years of Go
#79Earlier quoted context omitted.
Simply because it's limiting. Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck. For some people it's this feeling of being stuck that they don't like - others can live with it more easily. > I honestly also have no idea why Rust always makes an appearance in a Go thread Both Rust and Go people are ver…
The language is limited , but I do not find it limiting .