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…
Why Go is my favorite programming language
211–220 of 256 posts
Re: Why Go is my favorite programming language
#212Earlier 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…
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
#213Earlier 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).
Re: Why Go is my favorite programming language
#214Earlier 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'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
#215Earlier 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.
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
#216Earlier 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.
Re: Why Go is my favorite programming language
#217Earlier 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…
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
#218Earlier 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…
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
#219Earlier 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…
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
#220Earlier 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.
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.