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

81–90 of 110 posts

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#81

Post by pjmlp »

cygx wrote: post #74
4ad wrote: post #53

Earlier quoted context omitted.

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

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

Only as far as C++ standard requires C compatibility.

For Microsoft the future for native programming on Windows are C++ and .NET Native.

For compatibility with open source world and ISV that still care about C, the answer is the integration of Clang frontend with Visual C++'s backend, that is coming with Visual Studio 2015 Update 1.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#82

Post by whateveracct »

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?

You created a playground that intentionally avoids the nil ptr dereference.

https://play.golang.org/p/Cu4sE829ZZ

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#83

Post by jasonwatkinspdx »

psadauskas wrote: post #59
lostcolony wrote: post #4

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

I think that the solution to this problem is one of the few things that nodejs got right. Instead of declaring a global dependency on `require("D")`, you assign it a variable name. Then, each package can declare its sub-dependencies, and even when the versions differ, the different versions are kept in a different scope. https://nodejs.org/api/modules.html // Package A: import B from "B"; // A/node_modules/B/1.0.0 im…

I'm convinced this is the right approach: dependencies should be purely local to a module. The tooling should make it easy to detect you have a diamond, but let each module get what it needs. As generally everyone moves towards more continuous update and integration, at the end of the day it's all gonna be sha's anyhow.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#84

Post by to3m »

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

Visual studio 2013 supports enough C99 that you can get by (VLAs are the main omission). Visual Studio 2015 is supposedly fully conforming.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#85

Post by sophacles »

psadauskas wrote: post #59
lostcolony wrote: post #4

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

I think that the solution to this problem is one of the few things that nodejs got right. Instead of declaring a global dependency on `require("D")`, you assign it a variable name. Then, each package can declare its sub-dependencies, and even when the versions differ, the different versions are kept in a different scope. https://nodejs.org/api/modules.html // Package A: import B from "B"; // A/node_modules/B/1.0.0 im…

I think that this is a good approach - even better would be to include the version specifiers in the code itself...

    B = import("b", ">1.0")
    C = import("c", ">1.1 &&
etc.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#86

Post by flurie »

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…

> The entire Python scientific computing stack is resting on C.

Aren't a lot of NumPy modules reliant on fortran libraries?

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#87

Post by sanderjd »

howeyc wrote: post #8
nothrabannosir wrote: post #7

>> ..., and extreme abstraction capabilities in high level languages like Common Lisp, ... > Go has everything you mention in both of your lists of desirable attributes (depending perhaps on what you mean by "extreme abstraction") "perhaps"? By whose definition would it ever even come close to "extreme abstraction"? All of us assembly programmers, maybe? Don't get me wrong, I use Go where it makes sense. It has pros…

You missed what Donovan said, which answered the question. Obviously PL-enthusiasts (give me all the shiny! all the time!) wont like the answer though.

I don't really understand the claim that generic programming is "shiny". It is an old idea that has been implemented many times. It's totally fine that the Go team left out generics – it's their decision – but denigrating people who lament that decision as shiny-chasing PL-enthusiasts is unfair.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#88

Post by jerf »

whateveracct wrote: post #82
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?

You created a playground that intentionally avoids the nil ptr dereference. https://play.golang.org/p/Cu4sE829ZZ

You can actually create meaningful implementations of methods on nil pointers.

    if b == nil {
        fmt.Println(":)")
    } else {
        fmt.Println(b.emote)
    }
In this case, that's useless, but that's an artifact of the chosen example. I use it every so often in places where it happens to have meaning.

Go often treats nil as a legal value, which means that some of the things you might expect to crash don't, and when used idiomatically can sometimes make for shorter code. For instance, the "length" call on slices will happily take a nil and return 0, you can "append" to a nil slice and get a slice back, etc. Ultimately it's still a language with a null in it, though. There's no non-nil pointer type.

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#89

Post by wtetzner »

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…

> A huge portion of the GHC compiler is written in C.

Is it? I thought it was written in Haskell. Or are you referring to the GHC runtime?

Re: Alan Donovan and Brian Kernighan Answer Questions on Go

#90

Post by wtetzner »

jasonwatkinspdx wrote: post #83
psadauskas wrote: post #59

Earlier quoted context omitted.

I think that the solution to this problem is one of the few things that nodejs got right. Instead of declaring a global dependency on `require("D")`, you assign it a variable name. Then, each package can declare its sub-dependencies, and even when the versions differ, the different versions are kept in a different scope. https://nodejs.org/api/modules.html // Package A: import B from "B"; // A/node_modules/B/1.0.0 im…

I'm convinced this is the right approach: dependencies should be purely local to a module. The tooling should make it easy to detect you have a diamond, but let each module get what it needs. As generally everyone moves towards more continuous update and integration, at the end of the day it's all gonna be sha's anyhow.

But what do you do in a typed language? For example, suppose you have modules A and B, which depend on module C. Let's also say that module A has a function foo that return a value of type C.t, and module B has a function bar that accepts a value of type C.t.

Now let's say that module A is depending on version 1.0.0 of module C, and module B is depending on version 1.5.2 of module C.

Does B.bar(A.foo()) still work? Is type t the same in C version 1.0.0 and 1.5.2?

Post reply on HN