Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alan Donovan and Brian Kernighan Answer Questions on Go

features.slashdot.org

Post reply on HN
Print view View original

71–80 of 110 posts

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#71

Post by ustolemyname »

pcwalton wrote: post #64
lostcolony wrote: post #34

Earlier quoted context omitted.

For some things, yes. But there are a lot of potentially tricksy issues in doing that. Imagine a queueing library, for instance. You push something onto a queue created with library A, and then you want to read from library B (A and B are different version of the same library). Just about anything could happen (depending on how the library/language are implemented). You might get an error due to library B reading a d…

Making the version part of the type generally fixes these issues. Anything that could go wrong will nearly always go wrong at compile time.

Sure, that fixes some problems, but I don't understand how that would solve the first example listed above. Can you explain how the compiler would prevent this runtime error?

  // package a
  lib-v16.Queue(int32) // Stores in queue for version 16 of lib
  // package b
  int32 = lib-v18.DeQueue() // Loads from queue of version 18 of lib, which is empty
And even if we accept that you shouldn't have state in the package and the queue should be passed around, now we just have two packages (a & b) that use incompatible versions of lib for potentially no reason.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#72

Post by lostcolony »

skybrian wrote: post #70
lostcolony wrote: post #48

Earlier quoted context omitted.

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 i…

Yes, if you're going to check stuff in locally, you need to document which version you pulled to make the next upgrade easier. So it's not like nobody is keeping track of versions (or better yet, git commits). But this can all be done using a separate system. The build system itself doesn't need to know anything about versions. If you look at Bazel, it doesn't let you specify versions for target deps. Only the develo…

"You'll need to document which version you pulled" - so now you're tasked with describing "I got this version" (be that git commit or whatever), rather than it being explicit as part of the package "This is (x) version". So you get to reimplement something yourself, in a non-portable, non-self-describing way. Such an improvement.

Of course it could be done in a separate system. It could be done and tracked in a separate system even with version numbers. Go has just chosen to -require- you running your own package manager to make things stable, whereas for most languages it's optional and you can create a repeatable, portable build without it.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#73

Post by kornish »

throwa990323249 wrote: post #25
glittershark wrote: post #21

Earlier quoted context omitted.

Even beyond that is: var foo *bar foo.Baz() Accidentally dereferencing a null pointer in Go is dangerously easy

Actually that doesn't dereference a nil. https://play.golang.org/p/cjmflMBhF7 Why not learn the language before criticizing it?

To be fair, we don't know if `Baz` is a pointer or value receiver in the parent example. So it could: https://play.golang.org/p/fYO8jBbVQ5

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#74

Post by cygx »

4ad wrote: post #53
lobster_johnson wrote: post #50

Earlier quoted context omitted.

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 s…

> Are there still systems where you can't get a C99 compiler? In windows it's pretty annoying to get a C99 compiler. The "standard" compiler to do Windows development is Microsoft's, and it doesn't support C99. Of course you can install MinGW (gcc); most open source software on Windows uses it, but it's very unusual for the average Windows developer to even have gcc, and completely unheard of in the commercial space.…

Don't forget about the Intel C++ Compiler and Clang, never mind more obscure alternatives like TinyCC, Pelles C and Comeau C/C++.

There are options.

Also note that Microsoft has finally started improving C99 support with Visual Studio 2013 and 2015.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#75

Post by pcwalton »

ustolemyname wrote: post #71
pcwalton wrote: post #64

Earlier quoted context omitted.

Making the version part of the type generally fixes these issues. Anything that could go wrong will nearly always go wrong at compile time.

Sure, that fixes some problems, but I don't understand how that would solve the first example listed above. Can you explain how the compiler would prevent this runtime error? // package a lib-v16.Queue(int32) // Stores in queue for version 16 of lib // package b int32 = lib-v18.DeQueue() // Loads from queue of version 18 of lib, which is empty And even if we accept that you shouldn't have state in the package and the…

That is a theoretical problem, yes. In practice I've never seen it be an issue, because (a) global state is frowned upon and (b) packages that depend on each other so tightly tend to have dependencies at the type level, making the probability that such errors slip past the compiler very low.

To expand on (b), suppose that packages A and B depend on a shared queue managed by package C, as in your example. Because A and B have such tightly coupled logic, chances are that some package--either one of A and B, or some other package that depends on A and B--will have code that expects a type from "A's C" to be equivalent to a type from "B's C". At that point the code will fail to compile, and the programmer will fix the problem before it ever hits production. (Fixing this is easy because you can just inspect the lockfile to find all the crate versions in use.) Basically, static typing makes it such that, while the problem exists in theory, in practice its probability is so low as to not be a concern.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#76

Post by plexicle »

KyleBrandt wrote: post #3

The recently open sourced VSCode also has Go support now. Good first impression. The docs and type inference stuff are more convenient compared to the oracle plugin + GoSublime for sublime it seems.

I forced myself to use it all day yesterday and today so far (most of the time, I was writing Go).

I am loving it, honestly. Microsoft has a great product here.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#77

Post by mratzloff »

kornish wrote: post #73
throwa990323249 wrote: post #25

Earlier quoted context omitted.

Actually that doesn't dereference a nil. https://play.golang.org/p/cjmflMBhF7 Why not learn the language before criticizing it?

To be fair, we don't know if `Baz` is a pointer or value receiver in the parent example. So it could: https://play.golang.org/p/fYO8jBbVQ5

That's true, but it's pretty uncommon for a function to receive a value, and if so you either have a good reason for it or you're doing something wrong.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#78

Post by pcwalton »

ngrilly wrote: post #44
incepted wrote: post #38

Earlier 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.

If you call a function that returns nothing but an error, Go does not force you to acknowledge the error's existence and will silently allow you to drop it.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#79

Post by incepted »

Retra wrote: post #47
incepted wrote: post #42

Earlier quoted context omitted.

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…

> it just moves it to somewhere else.

That's exactly the point: not everyone along the method stack is forced to deal with it, only the one caller that knows how to handle it.

> The problem is that I don't know where it should be handled

Then don't handle it at all and let it crash the program. But at least you didn't add boiler plate simply bubbling up an Err at every level of the stack frames.

> If those were runtime exceptions, my program would just crash on error, which is the default I wanted

Sometimes it is, sometimes it isn't. Some exceptions should crash your program (runtime exceptions), others should be handled (checked exceptions). Languages that take correctness seriously should offer you both options.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#80

Post by pjmlp »

lobster_johnson wrote: post #50
agentultra wrote: post #43

Kernighan'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 s…

> Are there still systems where you can't get a C99 compiler?

- Commercial compilers for embedded space.

- Security areas where compilers are certified.

Post reply on HN