5 ms·

I think Go's strengths over C really start to shine when you're writing programs longer than 100 lines. Not having an exception mechanism, interfaces, single n

by jbooth 14y ago

I think Go's strengths over C really start to shine when you're writing programs longer than 100 lines. Not having an exception mechanism, interfaces, single namespace, no attaching methods to structs etc are fine in a small program, but they make bigger programs harder to digest pretty quickly.

Locke1689 14y ago
Calling Go's panic/recover system a proper exception mechanism is quite a stretch.
- sirclueless 14y ago
  I think he is referring more to go's "defer" functionality and out-of-band error return values more than panic/recover.
  - Locke1689 14y ago
    All of these things are just really poor exception mechanisms, in my opinion. It really looks like no one with an up-to-date PLT background was consulted in the design. I agree 100% with Andreas Rossberg (who now, somewhat ironically, works at Google): It is ironic that their motivation is to tame and restrict the use of exceptions, and then they replace them by something even richer and much less structured. I fail to see any pros of this proposal. It seems mostly equivalent to exceptions, i.e., you can easily express raise/try/finally as syntactic sugar, and likely the other way round. But it is (1) much more ad-hoc -- you cannot give a simple reduction semantics for this, (2) much less orthogonal -- tying `defer' in with function definitions, (3) dependent on mutation -- for recovering and returning alternative results, and implicitly in the semantics of `defer'. One consequence is the loss of beta-convertibility, which means that you as a programmer cannot take an arbitrary piece of code and turn it into a function anymore, or vice versa, eliminate a function by inlining its body. Such abstractions/refactorings are impossible in general under this proposal, or at least require transforming the relevant code in potentially non-trivial ways.
    - luriel 14y ago
      I disagree that panic/recover is worse than exceptions, I find it a more pleasant and lightweight mechanism, but the big difference is that panic/recover are not used like exceptions at all in Go, they are basically used only for programmer errors. They can be used for other things, but in those cases they never cross API-calls so you never have to worry about whatever a library you call might panic, you can basically ignore panic/recover exists completely, and do just fine, and that is what most people do most of the time.
      - Locke1689 14y ago
        Well, we can argue about whether or not an exception mechanism is the best way to deal with program error conditions, but my first point still stands, which is that Go does not have a proper exception mechanism. If defer/panic/recover were to be used as a true exception system you would run into all the issues Andreas details.
    - wickedchicken 14y ago
      > It really looks like no one with an up-to-date PLT background was consulted in the design. "Go is not meant to innovate programming theory. It's meant to innovate programming practice." I really like the out-of-band errors since they make control flow very explicit. With languages that rely on exceptions a lot (python, for example) I feel less in control of my program since 'anything can happen' remotely from my code.
      - Locke1689 14y ago
        Sorry, by "out-of-band errors" do you mean the error return value? This is not a terminology I'm familiar with. For any function which produces values of the form (a -> (b,e)) I'd refer to that as a product type. If this is what you're referring to, this is just a return value. There isn't really an exception system here. If you think about how return values work in C you'll note that it's usually some subset of the range which is defined for an actual value and some subset defined for an error condition. This is basically the same as (b,e), just worse type safety. Easy and efficient tuple constructions are hard to create in languages with manual memory management. Edit: Also, I didn't mean that Go should have innovated in PLT, only took advantage of innovations already established.
eswangren 14y ago
Well, the operating system you used to write that comment was probably written in C, so apparently it does in fact work in large projects. It has weaknesses to be sure, but I don't think lack of OO (I.e., structs with functions) is one of them.
- dllthomas 14y ago
  Particularly given that you can write OO code in C, and can decorate structs with functions, it's just messier.
  - StephenFalken 14y ago
    "Object oriented programming with ANSI-C": https://ritdml.rit.edu/handle/1850/8544 https://ritdml.rit.edu/handle/1850/8544
- jbooth 14y ago
  Duh. "Done" and "easily done" are different things. Structs with functions isn't the biggest deal, and namespaces can be simulated with a couple underscores. But I have a hard time with error handling if you don't have exceptions, any time I have a call stack more than 3-4 deep I find myself confused about how to treat certain errors. Then there's concurrency.
- tedunangst 14y ago
  It's worth noting that the bulk of the code in the kernel comes from 900 different network drivers, each of which could be considered a small program in its own right.

by jbooth 14y ago

Locke1689 14y ago

Calling Go's panic/recover system a proper exception mechanism is quite a stretch.

sirclueless 14y ago
I think he is referring more to go's "defer" functionality and out-of-band error return values more than panic/recover.
- Locke1689 14y ago
  All of these things are just really poor exception mechanisms, in my opinion. It really looks like no one with an up-to-date PLT background was consulted in the design. I agree 100% with Andreas Rossberg (who now, somewhat ironically, works at Google): It is ironic that their motivation is to tame and restrict the use of exceptions, and then they replace them by something even richer and much less structured. I fail to see any pros of this proposal. It seems mostly equivalent to exceptions, i.e., you can easily express raise/try/finally as syntactic sugar, and likely the other way round. But it is (1) much more ad-hoc -- you cannot give a simple reduction semantics for this, (2) much less orthogonal -- tying `defer' in with function definitions, (3) dependent on mutation -- for recovering and returning alternative results, and implicitly in the semantics of `defer'. One consequence is the loss of beta-convertibility, which means that you as a programmer cannot take an arbitrary piece of code and turn it into a function anymore, or vice versa, eliminate a function by inlining its body. Such abstractions/refactorings are impossible in general under this proposal, or at least require transforming the relevant code in potentially non-trivial ways.
  - luriel 14y ago
    I disagree that panic/recover is worse than exceptions, I find it a more pleasant and lightweight mechanism, but the big difference is that panic/recover are not used like exceptions at all in Go, they are basically used only for programmer errors. They can be used for other things, but in those cases they never cross API-calls so you never have to worry about whatever a library you call might panic, you can basically ignore panic/recover exists completely, and do just fine, and that is what most people do most of the time.
    - Locke1689 14y ago
      Well, we can argue about whether or not an exception mechanism is the best way to deal with program error conditions, but my first point still stands, which is that Go does not have a proper exception mechanism. If defer/panic/recover were to be used as a true exception system you would run into all the issues Andreas details.
  - wickedchicken 14y ago
    > It really looks like no one with an up-to-date PLT background was consulted in the design. "Go is not meant to innovate programming theory. It's meant to innovate programming practice." I really like the out-of-band errors since they make control flow very explicit. With languages that rely on exceptions a lot (python, for example) I feel less in control of my program since 'anything can happen' remotely from my code.
    - Locke1689 14y ago
      Sorry, by "out-of-band errors" do you mean the error return value? This is not a terminology I'm familiar with. For any function which produces values of the form (a -> (b,e)) I'd refer to that as a product type. If this is what you're referring to, this is just a return value. There isn't really an exception system here. If you think about how return values work in C you'll note that it's usually some subset of the range which is defined for an actual value and some subset defined for an error condition. This is basically the same as (b,e), just worse type safety. Easy and efficient tuple constructions are hard to create in languages with manual memory management. Edit: Also, I didn't mean that Go should have innovated in PLT, only took advantage of innovations already established.

eswangren 14y ago

Well, the operating system you used to write that comment was probably written in C, so apparently it does in fact work in large projects. It has weaknesses to be sure, but I don't think lack of OO (I.e., structs with functions) is one of them.

dllthomas 14y ago
Particularly given that you can write OO code in C, and can decorate structs with functions, it's just messier.
- StephenFalken 14y ago
  "Object oriented programming with ANSI-C": https://ritdml.rit.edu/handle/1850/8544 https://ritdml.rit.edu/handle/1850/8544
jbooth 14y ago
Duh. "Done" and "easily done" are different things. Structs with functions isn't the biggest deal, and namespaces can be simulated with a couple underscores. But I have a hard time with error handling if you don't have exceptions, any time I have a call stack more than 3-4 deep I find myself confused about how to treat certain errors. Then there's concurrency.
tedunangst 14y ago
It's worth noting that the bulk of the code in the kernel comes from 900 different network drivers, each of which could be considered a small program in its own right.