81–90 of 211 posts
> What is missing from the Go ecosystem? Personally, golang "IDE" experience is not as good as Java or even C++. For example, ycmd only supports subset of functions for golang. I miss ycmd-goto-references the most.
> What is missing from the Go ecosystem? Personally, golang "IDE" experience is not as good as Java or even C++. For example, ycmd only supports subset of functions for golang. I miss ycmd-goto-references the most.
Please do try atom with the go-plus package. It has goto def, can show "doc strings", and has decent integration with delve.
Earlier quoted context omitted.
Context? Are people actually switching to single dash flags? If so I'll get my pitchfork out of the closet.
The default golang flag package ( https://golang.org/pkg/flag/ ) does not implement gnu-style long-with-shortcut options. Instead, one and two-dash arguments are identical. For example, -enable-pants and --enable-pants are equivalent. Compare this with the GNU style where you can have -p or --enable-pants. Most go programs I've read use spf13's flag library, which is GNU-compatible.
Earlier quoted context omitted.
Not really. It's very verbose compared to Python, almost like Java.
Noo that's an overstatement. Of course it's not as clean as Python, it's statically typed. But type inference makes code way cleaner than your typical Java code (Javas type inference is improving, though).
No, it isn't since go lacks generics and dynamic types - which helps to reduce boilerplate(even if the latter isn't that effective).
> Of course it's not as clean as Python, it's statically typed.
There are cleaner statically typed languages then python - look at fp languages with type inference(ML dialect)
> But type inference makes code way cleaner than your typical Java code (Javas type inference is improving, though).
The typical java code is legacy, but for a fair comparison you should check out projectlombok [1]. Otherwise, Java is on the JVM which means there are alternatives like Scala/Kotlin etc.
Earlier quoted context omitted.
How does treating them as values force you to deal with them (except on principle)? Does the language force you to check the return value of every line of code? And the checking would only encompass expected errors, not unexpected ones, no? The unexpected ones (read: bugs) would simply be swallowed up and the actual problem would finally turn up far away in some other stack scope, no?
True, you can discard errors on purpose by assigning them to "_", which is an explicit way of saying "I do not care about this error happening". If you do that and get a panic down the line, you already know where to start debugging. That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it?
No, you don't panic, you are most likely to corrupt your data and maybe continue working as if everything was fine. If you are lucky, your code panics.
> ... you already know where to start debugging.
Grep all occurrences of "_"?
> That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it?
No, the exception carries all the context you need. If you ignored a previous exception, the next one won't be as useful as it could, but at least your code breaks loudly.
Earlier quoted context omitted.
The default golang flag package ( https://golang.org/pkg/flag/ ) does not implement gnu-style long-with-shortcut options. Instead, one and two-dash arguments are identical. For example, -enable-pants and --enable-pants are equivalent. Compare this with the GNU style where you can have -p or --enable-pants. Most go programs I've read use spf13's flag library, which is GNU-compatible.
Is this a remnant of Plan9 or something? Ugh, this is why I don't dabble in ecosystems with overly opinionated leaders. You have to know when to have a strong opinion and when to do things the standard way, and some people can't do that.
Earlier quoted context omitted.
> It is pretty readable, but really non-functional too There are projects starting to fix that: https://github.com/asteris-llc/gofpher
I think he meant non-functional in the sense of "not functioning", not functional programming. Neither of his immediately following complaints have anything to do with functional programming.
Earlier quoted context omitted.
However it treats them as product values (tuples) instead of sum values (Either), so it's perfectly possible to ignore the error and take the result anyway.
Ignoring on purpose is fine. The problem is when the only return value is an error which can be ignored simply by not assigning the result to a variable. Forcing the user to do: _ = f.Close() ... in order to explicitly ignore the error would be nicer, but then, there are many functions which are known to never be checked for their errors, like fmt.Println. That's why the typical advice is to use errcheck, which has f…
In Java println is checked for errors, as it should be. Every Java program that does println either aborts or deals with the error in some way.
It matters. Take any program that writes to stdout and run it with ">&-" to close stdout. Because of unix, the next file it opens will be file descriptor 1 and the program will start writing the console output to the file. You want the program to abort instead of trashing a file, and especially not to trash /etc/passwd.
That's why you don't want to ignore errors, because any time you do there can be unintended and hard to imagine consequences -- even something as simple as writing to the console. Simply put, Go encourages buggy programs with poor error handling.
Earlier quoted context omitted.
How does treating them as values force you to deal with them (except on principle)? Does the language force you to check the return value of every line of code? And the checking would only encompass expected errors, not unexpected ones, no? The unexpected ones (read: bugs) would simply be swallowed up and the actual problem would finally turn up far away in some other stack scope, no?
True, you can discard errors on purpose by assigning them to "_", which is an explicit way of saying "I do not care about this error happening". If you do that and get a panic down the line, you already know where to start debugging. That's much better than having an exception bubble up from deeeeep inside your code with some context-less cryptic message or number, isn't it?
I don't see how that follows. A stack trace (as initially cryptic as it seems) is a record of all the code that would have affected the current buggy state you find yourself in. If anything, a stack trace isn't comprehensive enough, ideally it would include all known/named values at every level of the stack... a large quantity of information, to be sure, but perhaps it could be narrowed down by diffing each stack level with the previous one or something. But if you could have those 2 things, you would have literally ALL the information you needed to fix the bug. Since bugs are programmer-unexpected states, and the stack trace plus the known values at each stack level are LITERALLY the entire state.
So correct me if I'm wrong, if you don't assign an error to a variable on the same line in Go, it throws? Because it was my understanding that there were absolutely no throws at all in Go. Or is it only that certain kinds of statements are expected to possibly error, and must therefore be assigned to a variable (or _)?
Earlier quoted context omitted.
Context? Are people actually switching to single dash flags? If so I'll get my pitchfork out of the closet.
The default golang flag package ( https://golang.org/pkg/flag/ ) does not implement gnu-style long-with-shortcut options. Instead, one and two-dash arguments are identical. For example, -enable-pants and --enable-pants are equivalent. Compare this with the GNU style where you can have -p or --enable-pants. Most go programs I've read use spf13's flag library, which is GNU-compatible.