Earlier quoted context omitted.
I thought it was just syntax highlighting. Any link documenting VSCode's Go suppport?
Found it: https://github.com/Microsoft/vscode-go
Thanks.
Alan Donovan and Brian Kernighan Answer Questions on Go
41–50 of 110 posts
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#42Earlier quoted context omitted.
It's also trivial to "just ignore errors" in a language based on checked exceptions: try { ok = foo() } catch (Exception e) { // Do nothing } Checked exceptions don't save you from "this kind of sloppy programming".
And it'll happen frequently, because if you're just trying to test out `ok = foo()` and you're not sure if it'll work, then you've got to write four lines of awful boilerplate and go read an API reference just to get it to compile. Checked exceptions are supposed to encourage correctness, but there's no fudge room for playing around, so they are very not fun. As an aside, I once tried using a crypto library to do som…
If you don't know how to handle an exception, just add it to your `throws` clause and let a caller handle it. That's the whole point of exception: letting you choose who is the most appropriate to handle the error.
Return value errors like Go implements forces everyone to care about all errors, at all times, even those they can't handle, which is why you see the pattern
ok, err:= Foo()
if err {
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#43Kernighan's response to the C question was rather odd -- where is this myth that C is only used in embedded systems and drivers coming from?
The Linux kernel is still written in C.
Ben Klemens, author of 21st Century C, leads the statistical computing group for the research arm of the U.S. Census Bureau. He models complex systems and computations in C.
The entire Python scientific computing stack is resting on C.
A huge portion of the GHC compiler is written in C.
Many AAA game developer studios are writing their engines in C (with vendor supplied C++ compilers, but C none-the-less).
And do people really write C89 for greenfield projects today? C99 is pretty amazing and has added some great features to the language. C11 might be the trivial change having only added some atomic operators (depending on whether you think this is trivial) and rescinding VLAs (though most compilers will probably continue to support them anyway).
I think Go is a perfectly fine language but it seems like perhaps the group is a little out of touch with the rest of the world judging by replies to questions like this.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#44Earlier quoted context omitted.
It's also trivial to "just ignore errors" in a language based on checked exceptions: try { ok = foo() } catch (Exception e) { // Do nothing } Checked exceptions don't save you from "this kind of sloppy programming".
But you have to write the `catch` (or a `throws`). That's the point. Now if you choose to handle this stupidly, that's entirely your fault, but at least the compiler did its jobs by forcing you to think about the error case. In Go, the compiler doesn't enforce anything.
How many lines of Go have you written before writing this?
In Go, as in Java with checked exceptions, the compiler forces the programmer to handle the error.
Using _ in Go is not idiomatic. It's the exact equivalent of using a try/catch block with nothing in the catch block in Java.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#45Kernighan's response to the C question was rather odd -- where is this myth that C is only used in embedded systems and drivers coming from? The Linux kernel is still written in C. Ben Klemens, author of 21st Century C, leads the statistical computing group for the research arm of the U.S. Census Bureau. He models complex systems and computations in C. The entire Python scientific computing stack is resting on C. A h…
The trend in games these days is to move to C++ but there is still C used in some places.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#46I never knew that the decision to not have versioning built into go was because of the diamond dependency problem. This makes a lot of sense now that I think about it. I wonder what alternatives to manually versioning things the go team is considering. Also, at the beginning the Go team wasn't all that enthusiastic about an IDE, but its great to see that Go will get an IntelliJ grade IDE soon, so that works for me :)
I really am not a fan of the lack of versioning, even with that explanation. Of course diamond dependencies are a problem. But they haven't actually fixed that problem; they've just declared a method for picking one of the two dependencies that is ill defined ("whichever one you happen to have pulled in first"). At least with versioning I get told that there's an incompatibility in the expectations between two librar…
The fix for Google is to check in all third party libraries locally, so you get the same version as everyone else in the company until someone decides to check in an upgraded version. It works fine and anyone else is free to do the same.
But that requires a monorepo that scales and people to test and check in the upgrades, so it doesn't work well for open source development, which is why people are working on alternatives.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#47Earlier quoted context omitted.
And it'll happen frequently, because if you're just trying to test out `ok = foo()` and you're not sure if it'll work, then you've got to write four lines of awful boilerplate and go read an API reference just to get it to compile. Checked exceptions are supposed to encourage correctness, but there's no fudge room for playing around, so they are very not fun. As an aside, I once tried using a crypto library to do som…
If you don't know how to handle an exception, just add it to your `throws` clause and let a caller handle it. That's the whole point of exception: letting you choose who is the most appropriate to handle the error. Return value errors like Go implements forces everyone to care about all errors, at all times, even those they can't handle, which is why you see the pattern ok, err:= Foo() if err { every ten lines in Go…
You (the programmer) still have to handle it. If I (as a person) don't know how to handle the exception, passing it up the call stack doesn't solve the problem, it just moves it to somewhere else. The problem is that I don't know where it should be handled, because it was exposing cryptic and obscure exception types that probably make sense to someone who really understands cryptography. I don't, so I just can't use that library.
If those were runtime exceptions, my program would just crash on error, which is the default I wanted. I didn't want to pollute my code with error handling stuff just to try out some simple functionality. If they were runtime exceptions, I could learn to use the code from the ground up, not by having to understand the whole thing at once.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#48Earlier quoted context omitted.
I really am not a fan of the lack of versioning, even with that explanation. Of course diamond dependencies are a problem. But they haven't actually fixed that problem; they've just declared a method for picking one of the two dependencies that is ill defined ("whichever one you happen to have pulled in first"). At least with versioning I get told that there's an incompatibility in the expectations between two librar…
The fix for Google is to check in all third party libraries locally, so you get the same version as everyone else in the company until someone decides to check in an upgraded version. It works fine and anyone else is free to do the same. But that requires a monorepo that scales and people to test and check in the upgrades, so it doesn't work well for open source development, which is why people are working on alterna…
Right, but you could do that with version numbers, too. The difference between updating from "whatever version was pulled in at the time we first set up the repo with this library" and "current" is no different than updating from "version X" to "version Y", except that you don't know what the differences are, and there's no way to determine that it would be easier (and possible) to update to version X.1, since that includes the fix/feature that triggered the desire for an update, and doesn't break as many things, so requires less work.
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#49Earlier quoted context omitted.
But you have to write the `catch` (or a `throws`). That's the point. Now if you choose to handle this stupidly, that's entirely your fault, but at least the compiler did its jobs by forcing you to think about the error case. In Go, the compiler doesn't enforce anything.
How many lines of Go have you written before writing this? In Go, as in Java with checked exceptions, the compiler forces the programmer to handle the error. Using _ in Go is not idiomatic. It's the exact equivalent of using a try/catch block with nothing in the catch block in Java.
Or not checking for the exception at all. Certain classes of errors can and should be allowed to pass up the call stack and cause your program to die (something strange that I wasn't expecting and don't know how to handle happened, and now I'm in a bad state - safer to exit)
Re: Alan Donovan and Brian Kernighan Answer Questions on Go
#50Kernighan's response to the C question was rather odd -- where is this myth that C is only used in embedded systems and drivers coming from? The Linux kernel is still written in C. Ben Klemens, author of 21st Century C, leads the statistical computing group for the research arm of the U.S. Census Bureau. He models complex systems and computations in C. The entire Python scientific computing stack is resting on C. A h…
Kernighan wasn't the one claiming that C was mostly used for embedded systems and drivers; that was the guy who posed the question. Kernighan only agreed that C is still popular in that space.
As for C99, I would love to see some hard stats about rate of adoption. Personally I can't imagine starting out on a new project and not use C99, but then the hard-core C contingency is a pretty conservative bunch. (Are there still systems where you can't get a C99 compiler?)