Live data from Hacker News

Why Go is my favorite programming language

michael.stapelberg.de

211–220 of 256 posts

Re: Why Go is my favorite programming language

#211

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?

Re: Why Go is my favorite programming language

#212
post #193

Earlier quoted context omitted.

> I see very little in terms of features or problems they solve that distinguishes Java, JavaScript, Go, Scala and C# from each other when it comes to writing Web backends. So in a way, we agree, as that was my whole point - Go & it's predecessors (ASP, PHP, JS, ...) are mostly only good for Web backends: E.g., literally all Go developers I know personally are either fresh out of college or ex PHP programmers, ASPers…

What I disagree with first and foremost is your claim that Go is not an alternative for JVM/.NET languages and hence shouldn't be compared to them. All of these languages are direct competitors in a number of areas today (Web backends, infrastructure services, database systems) and based on language/runtime capabilities (as opposed to cultural and library availability) I see almost no area where there is no potential…

I continue to fail to see your argument: First you claim that any language can be shoehorned into any usage, and then (last paragraph) you yourself show why that isn't quite true.

Plus, as said, Go's language "facilities" are a long shot from Java/Scala/C#'s, while having GC can be prohibitive in other areas (C++, Rust, embedded systems, real-time transaction processing), and some areas (e.g. space exploration) even need the ability to change the runtime code on the fly.

Re: Why Go is my favorite programming language

#213

Earlier quoted context omitted.

You keep mixing up what languages are currently used for and what they are suitable for. There are very few projects for which you couldn't use Go, JVM and .NET languages equally well purely on the basis of language and runtime features (ignoring hiring, library availability and other cultural aspects)

The entire category of "you need non-standard datastructures" works perfectly well on the JVM and .NET CLR, but is entirely useless in Go (thanks to missing generics).

Of course you can write non-standard data structures in Go. The fact that Go makes this more inconvenient or less efficient than languages that have generics is exactly why we compare the languages, not a reason for not comparing them as fnl has suggested.

Re: Why Go is my favorite programming language

#214

Earlier quoted context omitted.

It is way safer than void * : A void * can be cast to (and then used as) any arbitrary type, leading to all sorts of undefined behavior. On the other hand, the following code will just panic() (i.e. exit cleanly without corrupting memory). var x int = 5 var i interface{} = &x *(i.(*string)) = "boom"

> It is way safer than void * I said "it's unsafe", not "it's not safer than void*". > (i.e. exit cleanly without corrupting memory). This makes no sense. If it exits, who cares if the memory of the process is corrupted? Also, this is the point: it exits instead of the compiler telling you this code will crash before you ship it. That's the point of static type safety (which Go doesn't provide in this case): it lets…

> I said "it's unsafe", not "it's not safer than void".

I'm sorry, but then you're simply in the wrong thread. You where replying to a interface{} vs. void comment, so that's what you should be talking about.

Re: Why Go is my favorite programming language

#215
post #169

Earlier quoted context omitted.

I know this is repeated often, but only because it apparently still has to: interface{} is very different from void*. It carries type-information with it. That makes it safe.

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. Which was exactly my point. Equating the two is intellectually dishonest.

Re: Why Go is my favorite programming language

#216
post #150

Earlier quoted context omitted.

> Go is the first language where I can actually access the original socket permission error because it was actually passed up. Now try to trace them as easily as exceptions. Oh wait, you can't unless you wrap Go errors into some struct from a library that isn't in the std lib therefore everybody has different systems to trace errors /s i'll take exceptions over this (which go has, panic/defer). error is just a conven…

I'll take Either where I can guarantee I know what I'm dealing with and that it's dealt with rather than the honors system Go offers.

Go is basically using multiple return values as a half baked Either type, only you're on your own if you want to pass it over a channel or store it anywhere.

Re: Why Go is my favorite programming language

#217
post #78

Earlier quoted context omitted.

nil is always equal to nil. You might be confusing it with comparing a nil pointer to a pointer to a nil pointer, which are not equal.

The nil-interface wart actually does result in comparison issues, and it's something that trips people up all the time: package main import ( "fmt" "io" ) type Thing struct{} func (t *Thing) Close() error { return nil } func main() { var x *Thing var y io.Closer = x fmt.Printf("x == nil -> %#v\n", x == nil) // true fmt.Printf("y == nil -> %#v\n", y == nil) // false } Here, both x and y are conceptually nil, but y can…

> Here, both x and y are conceptually nil, but y cannot be compared to nil.

I disagree with the "conceptual nilness" of y. x is a perfectly fine and usable implementation of io.Closer. It doesn't even panic. Having a nil-check (i.e. "does this interfaces contain a value?") return true seems dishonest to me.

I agree, that it was a bad choice to call both the zero-value of pointers and the zero-value of interfaces "nil". But in general, the possibility of nil-pointers being valid values and implementers of interfaces is useful. For example if you have a linked list or graph-structure.

I also asked about it on reddit and got this answer: https://www.reddit.com/r/golang/comments/6sktsr/typed_nils_i...

Re: Why Go is my favorite programming language

#218
post #212

Earlier quoted context omitted.

What I disagree with first and foremost is your claim that Go is not an alternative for JVM/.NET languages and hence shouldn't be compared to them. All of these languages are direct competitors in a number of areas today (Web backends, infrastructure services, database systems) and based on language/runtime capabilities (as opposed to cultural and library availability) I see almost no area where there is no potential…

I continue to fail to see your argument: First you claim that any language can be shoehorned into any usage, and then (last paragraph) you yourself show why that isn't quite true. Plus, as said, Go's language "facilities" are a long shot from Java/Scala/C#'s, while having GC can be prohibitive in other areas (C++, Rust, embedded systems, real-time transaction processing), and some areas (e.g. space exploration) even…

>First you claim that any language can be shoehorned into any usage

I did not claim that at all.

What I dispute is that the set of tasks for which both Go and Java/.NET are suitable is so small that it makes no sense to compare them.

People often have a choice of using Go, Java, Scala, C#, etc, for the same task and that is why a comparison makes perfect sense.

Re: Why Go is my favorite programming language

#219
post #193

Earlier quoted context omitted.

> I see very little in terms of features or problems they solve that distinguishes Java, JavaScript, Go, Scala and C# from each other when it comes to writing Web backends. So in a way, we agree, as that was my whole point - Go & it's predecessors (ASP, PHP, JS, ...) are mostly only good for Web backends: E.g., literally all Go developers I know personally are either fresh out of college or ex PHP programmers, ASPers…

What I disagree with first and foremost is your claim that Go is not an alternative for JVM/.NET languages and hence shouldn't be compared to them. All of these languages are direct competitors in a number of areas today (Web backends, infrastructure services, database systems) and based on language/runtime capabilities (as opposed to cultural and library availability) I see almost no area where there is no potential…

For the sake of argument, let's assume Go were equal to Java and C# (nb, I think that is not true, but let's look at the issue from that perspective).

Can Go replace C#? That's MS land and comes with the .Net platform. I think nobody will think Go is even remotely gathering its following from C# and the amount of tooling you get there is probably the largest set you can get.

What about Java? That has 20 years of entrenched Enterprise usage. So to make a dent on that, it not only has to have equal languages facilities, it also needs an equivalent ecosystem (maybe?) and, crucially, has to be better: Java replaced C++ as it's a much better fit at what it's used for due to GC and "no" resource management. But I certainly don't see anything that Go does that makes it much better over Java as Java was in it's day over C++.

So no, I don't see Go replacing .Net or the JVM anytime soon.

Re: Why Go is my favorite programming language

#220
post #212

Earlier quoted context omitted.

I continue to fail to see your argument: First you claim that any language can be shoehorned into any usage, and then (last paragraph) you yourself show why that isn't quite true. Plus, as said, Go's language "facilities" are a long shot from Java/Scala/C#'s, while having GC can be prohibitive in other areas (C++, Rust, embedded systems, real-time transaction processing), and some areas (e.g. space exploration) even…

>First you claim that any language can be shoehorned into any usage I did not claim that at all. What I dispute is that the set of tasks for which both Go and Java/.NET are suitable is so small that it makes no sense to compare them. People often have a choice of using Go, Java, Scala, C#, etc, for the same task and that is why a comparison makes perfect sense.

As I've explained here extensively, I don't think that Go is replacing any of the more fancy languages like Scala, Clojure, D, ... And as for C++, that's in a different domain. Finally, Java & C# are entrenched and Go has no decisively better advantage that would make it worth giving up those code bases (like Java was over C++' resource management).

I do agree that Go has made the life of legions of PHP and Node.JS developers easier. And it is nicer to do web development in Go rather than C and Python.

However, claiming that Go "eats everybody's lunch" is rather outlandish.

Post reply on HN