Live data from Hacker News

Why Go is my favorite programming language

michael.stapelberg.de

241–250 of 256 posts

Re: Why Go is my favorite programming language

#241

Earlier quoted context omitted.

And how do I get the same type out that I put in? I'd end up with Java 1 style programming, no generics, and having to cast atuff from Object/interface{} everywhere. interface{} is like Object, if it even exists once in your code, it's broken.

> And how do I get the same type out that I put in? You can only get out the same type you put in. Presumably in your code you know that collection of Foo objects contains Foos, so you can just do: if foo, ok = collection.get().(Foo); !ok { return errors.New("expected a Foo") } Write a few wrapper functions and you're done.

So, we’re back in Java 1.0, and using Object and just casting back again?

Seriously, this is why generics exist. I want to write it once, use it everywhere again, and want to have the compiler know if I made a mistake.

Re: Why Go is my favorite programming language

#242
post #63

What would convince an avid Python user to switch to Go st this point? Let’s narrow down the scope to an API backend to be more specific (isn’t that’s where Go’s performance thrives?)

Python is my favorite language and I really liked Go as I read about it. When time came to actually learn and use it, I was... Disappointed.

Sticking with python still, for the time being.

Re: Why Go is my favorite programming language

#243

I really dislike Go as a language, it has very few means of abstraction and it feels depressing that people think you have to throw out decades of PLT research to achieve perceived clarity like this. That said, these reasons are almost all linked to tooling, which is something that I have to admit Go gets right, but they're not intrinsically linked to the language itself and its feature minimalism. I wish there were…

While I neither love nor hate Go - I'm really confused about "Go gets tooling right". Is it mostly about the built-in gofmt and compiling to binary? Dependency management is far from right, for example, and so are stuff like hot code reloading, remote debugging, containerized development, etc. How does Go get tooling right compared to, say node/npm or java?

Tooling in regards to formatting: I guess you get to appreciate it when using gofmt automatically with your editor, eg. with Go extension for Visual Studio Code or vim-go.

Turns out pretty much as he says (see given example at play.golang.org). You just type in the style you always have, but with the certainty that in the end it will be the same as the other's, easy to read, easy to maintain, and uncontroversial in terms of formatting. You could agree on google-java-format, I guess. But also potentially waste plenty of time on the decision itself :-) compared to a dictate and tool originating from the language itself.

Re: Why Go is my favorite programming language

#244
post #101
post #84

Earlier quoted context omitted.

Google doesn't invest heavily in Go. It almost certainly invests more in JS, Python, Java, and C++. I think the difference is philosophical--Go doesn't pretend that every obscure edge case deserves equal support to the main case, and so its tooling is much simpler.

I'm not sure where you get your information from, but Google definitely invests a substantial amount in Go. - Paid some of the most celebrated engineers to work on it full time. - Support it as a first class language in GCP - Support it as a first class language internally If you want to see a language Google doesn't invest much into, look at Dart

Google pays a small team to maintain the language, but developing the language is very likely not a business objective in remotely the same capacity as .Net is for Microsoft or even Swift for Apple. It's not even a major headliner for Google's I/O conference. I would like to know where you're getting your information about Google not investing in Dart, because last time I checked, Google appeared to be investing considerably in Dart (this was back before the Dart vs TypeScript battle was settled though, so perhaps Google pulled up its investment).

At any rate, Go's tools don't require significant investment because they are designed for simplicity (there is no package repository, no language-agnostic/fully-imperative build scripting language or project metadata files, no bring-your-own-unit-test-framework, no docstring syntax, etc). Go tools err on the side of supporting too few use-cases, where Java, Python, .Net, C++, etc build tooling typically emphasize explicit configuration over sane defaults.

Re: Why Go is my favorite programming language

#245
post #209
post #43

Earlier quoted context omitted.

Go has error handling, it doesn't have exceptions for non-exceptional error cases.

I'm starting to find it weird that things like "error while passing string as int" trigger an exception rather than return an error. There are always error cases to check when handling user input. It's a natural part of the program flow, not really an exception. I would expect an 'exception' to be something like out of memory or disk corruption.

Presumably you mean "user provided a string which was supposed to be decodable as an int, but was not"? If so, then yes, this should be handled as an input error and not as an exception (programmer error). I don't know if you meant this as a criticism of Go or not, but you should find that Go programs almost always return errors (as opposed to panicking) under such circumstances.

Re: Why Go is my favorite programming language

#246

Earlier quoted context omitted.

You're confused, Java's tooling is more complex/less intuitive. It doesn't matter where the dependency data lives on your system; it's completely transparent to you.

> It doesn't matter where the dependency data lives on your system; it's completely transparent to you. Until some idiot checks it in on git despite the .gitignore (yes, this is possible, as I discovered after people accidentally did it). Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I…

> Until some idiot checks it in on git despite the .gitignore (yes, this is possible, as I discovered after people accidentally did it).

This seems like a ridiculous edge case to optimize for. It's rare and trivially corrected.

> Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I don’t have to care where dependencies are, or what transpilation steps are happening.

You don't have to configure a $GOPATH in Go. If you don't specify it, it defaults to $HOME/go. Just use `dep` to manage your versioned dependencies or `go get` if you're prototyping. Unlike Gradle, there is no scripting language to learn--static binaries and native dependencies are supported with no extra configuration, and everything is fast without a complicated daemon to install.

Re: Why Go is my favorite programming language

#247

Earlier quoted context omitted.

Couldn't agree more, a much better investment of anyones time. C++ won't suddenly refuse to solve your problems because they don't fit into an arbitrarily limited view of the world. And some of the stuff coming out of standardization lately is simply awesome.

Can you share some of it. Trying to get better at C++ here.

Sure thing. Bear in mind that this is my way of doing it; plenty of people will yell blasphemy at the choices I make, and some may well turn out to be suboptimal without 32 years of experience to back them up.

https://github.com/andreas-gone-wild/snackis

Re: Why Go is my favorite programming language

#248

Earlier quoted context omitted.

I don't care what we call it, it's still confusing as hell.

Yeah, indirection can be confusing to new programmers, but its absolutely fundamental, so it's better to get used to it than to complain about it.

Except I have 32 years of daily practice and plenty of experience from most paradigms/languages/kinds of software out there. I'm guessing similar goes for some of the hundreds of people who complain about the same thing.

This attitude is exactly why many choose to stay away from Go and its community. The constant denial of any problems and claims that everyone else got it wrong. I don't know where it started, most probably Pike & co; but its not very constructive.

Re: Why Go is my favorite programming language

#249
post #169

Earlier quoted context omitted.

Memory safe, yes. Type safe, no.

Yes, Type safe. You can not interpret something as a different kind of type via the use of interface{}. Contrast that with void-pointers, which make that so easy as to be a common bug-source. It's not statically type-checked, yes. That's fine too, in my opinion, but also irrelevant for a comparison with void-pointers (because they also don't provide that). In summary, interface{} is strictly better than void-pointers…

> Yes, Type safe. You can not interpret something as a different kind of type via the use of interface{}.

Interesting; for some reason, I was under the impression that you could cast an `interface{}` arbitrarily, but from trying it out, you're absolutely correct. (I should definitely make sure to try these things out before confidently asserting about them...)

> interface{} is strictly better than void-pointers

No arguments here; even if for some reason they weren't type safe (which they are, much to my surprise), I'd still agree with you there.

Re: Why Go is my favorite programming language

#250

Earlier quoted context omitted.

Yeah, indirection can be confusing to new programmers, but its absolutely fundamental, so it's better to get used to it than to complain about it.

Except I have 32 years of daily practice and plenty of experience from most paradigms/languages/kinds of software out there. I'm guessing similar goes for some of the hundreds of people who complain about the same thing. This attitude is exactly why many choose to stay away from Go and its community. The constant denial of any problems and claims that everyone else got it wrong. I don't know where it started, most pr…

If you think that's my attitude, you don't know me. I have lots of criticism for the language, but pretending a pointer isn't a pointer isn't the solution to people not understanding indirection.
Post reply on HN