4 ms·

> The SQLite developers believe that the lack of assert() disqualifies Go as a language for serious development work. Great comment.

rileymat2 8y ago
I did not understand this comment, as they also wrote ALWAYS, NEVER and testcase. Why could you not write your own assert in Go? (I have not programmed in Go)
- drb91 8y ago
  You can always log to stderr with a stack trace and exit with a non zero static code. I’m guessing they’re referring to the fact that the built in panic keyword can be “caught” further up the stack a la an exception.
  - hermitdev 8y ago
    IMO, far better to log, then abort/core. I want to be able to inspect the state of the failed case, not just know that it failed.
    - catlifeonmars 8y ago
      It’s far better to let the caller decide. As a user of a library, I absolutely do not want a library terminating my process. Sure, some programs can benefit from this, but some programs need to guarantee that they keep running. Being able to recover (Go’s counterpart to panic()) allows the caller to decide which behavior they want.
      - hermitdev 8y ago
        I'm not sure I agree. There's a very, very small limited set of conditions that a client can recover from a condition that would trigger an assertion failure. Dont want an abort? Then use the release libs where those have been preprocesed out. Conversely, at a former employer we used a set of 3rd party database libs for ODBC on Linux that for the smallest config error would emit nothing to stderr and call exit(1) from a shared lib. that was beyond annoying
        catlifeonmars 8y ago
        I was afraid someone would mention preprocessing out the asserts :) That also has its advantages, but would argue that it is impossible to selectively opt in or out. Honestly, for a well tested piece of code, the point is moot, since the assert(s) will never evaluate false anyway.
        hermitdev 8y ago
        > I was afraid someone would mention preprocessing out the asserts :) Problem is, you need to understand what you're using, and like it or not, assert is defined as a macro by the C standard. And, assert is conditionally defined (and it's not the only conditionally defined macro). I know its long, verbose, and dry; but if you want to understand C (or C++ for that matter), you really need to read the ISO standards that correspond to the implantation.
        drb91 8y ago
        You can also easily enable runtime failures so the point is indeed moot.
      - int_19h 8y ago
        If you're in the same process as the code that had its invariant fail, how can you ensure that your process is in a safe state afterwards? A failed invariant, by definition, means that you're in uncharted territory - any anticipated failures are (assuming proper design) reported via the usual error mechanisms.
- fwip 8y ago
  I dunno either, because it's incredibly trivial. func assert(cond bool){ if !cond { panic("whoopsies") } }
  - rabidrat 8y ago
    And then you can just #define assert(...) to eliminate it...oh wait, Go doesn't have a macro-preprocessor.
    - pstuart 8y ago
      To play along.... Go does have build tags, so one could have 2 files for the assert function, each with opposite build tag logic. It does allow for an effective NOP (it would be a stub function and I believe the compiler would eliminate that).
      - helper 8y ago
        I tested this and it does indeed eliminate that code.
        deathanatos 8y ago
        I'm wondering if it inlines it (and thus eliminates it). But this would come with a performance penalty: it makes the function you assert() in no longer a leaf function (it calls assert()) and AFAIK, Go only inlines leaf functions. (So, any function in which you call assert() is no longer eligible for inlining.)
        helper 8y ago
        chrchang523 is correct. In my test the caller function can still get inlined.
        chrchang523 8y ago
        deathanatos: Go 1.12 can inline non-leaf functions, and I’d be surprised if it still fails to do the right thing here.
marvy 8y ago
To draw_down: your comments are showing up as dead, As for assert in Go... couldn't you just make a function that takes a Boolean and panics?
- everdev 8y ago
  You could, but then when you get an error, you'll see the file and line number of the assert function rather than the code that actually produced the error.
  - bbatha 8y ago
    The runtime package allows you to grab the current trace, you can just pop the last frame off and print that.
    - everdev 8y ago
      True. The only other challenge is that in production software you rarely want to call panic()
      - IanS5 8y ago
        As another comment mentioned you can just use build tags to make assert a no-op in release builds
- rabidrat 8y ago
  Also, there is no way to eliminate the assert clause in a high-performance (release) build.
zaroth 8y ago
It seemed random and out of place to me. Like some sort of Wiki vandalism. Why do I care about their opinion of Go in SQLite dev docs?
- smitty1e 8y ago
  Whoever wrote that was probably shooting from the Hipp.
- geezerjay 8y ago
  > Why do I care about their opinion of Go in SQLite dev docs? Apparently some peoplr care, considering the number of comments on how Go can, does and should handle this usecase.

rileymat2 8y ago

I did not understand this comment, as they also wrote ALWAYS, NEVER and testcase. Why could you not write your own assert in Go? (I have not programmed in Go)

drb91 8y ago
You can always log to stderr with a stack trace and exit with a non zero static code. I’m guessing they’re referring to the fact that the built in panic keyword can be “caught” further up the stack a la an exception.
- hermitdev 8y ago
  IMO, far better to log, then abort/core. I want to be able to inspect the state of the failed case, not just know that it failed.
  - catlifeonmars 8y ago
    It’s far better to let the caller decide. As a user of a library, I absolutely do not want a library terminating my process. Sure, some programs can benefit from this, but some programs need to guarantee that they keep running. Being able to recover (Go’s counterpart to panic()) allows the caller to decide which behavior they want.
    - hermitdev 8y ago
      I'm not sure I agree. There's a very, very small limited set of conditions that a client can recover from a condition that would trigger an assertion failure. Dont want an abort? Then use the release libs where those have been preprocesed out. Conversely, at a former employer we used a set of 3rd party database libs for ODBC on Linux that for the smallest config error would emit nothing to stderr and call exit(1) from a shared lib. that was beyond annoying
      - catlifeonmars 8y ago
        I was afraid someone would mention preprocessing out the asserts :) That also has its advantages, but would argue that it is impossible to selectively opt in or out. Honestly, for a well tested piece of code, the point is moot, since the assert(s) will never evaluate false anyway.
        hermitdev 8y ago
        > I was afraid someone would mention preprocessing out the asserts :) Problem is, you need to understand what you're using, and like it or not, assert is defined as a macro by the C standard. And, assert is conditionally defined (and it's not the only conditionally defined macro). I know its long, verbose, and dry; but if you want to understand C (or C++ for that matter), you really need to read the ISO standards that correspond to the implantation.
        drb91 8y ago
        You can also easily enable runtime failures so the point is indeed moot.
    - int_19h 8y ago
      If you're in the same process as the code that had its invariant fail, how can you ensure that your process is in a safe state afterwards? A failed invariant, by definition, means that you're in uncharted territory - any anticipated failures are (assuming proper design) reported via the usual error mechanisms.
fwip 8y ago
I dunno either, because it's incredibly trivial. func assert(cond bool){ if !cond { panic("whoopsies") } }
- rabidrat 8y ago
  And then you can just #define assert(...) to eliminate it...oh wait, Go doesn't have a macro-preprocessor.
  - pstuart 8y ago
    To play along.... Go does have build tags, so one could have 2 files for the assert function, each with opposite build tag logic. It does allow for an effective NOP (it would be a stub function and I believe the compiler would eliminate that).
    - helper 8y ago
      I tested this and it does indeed eliminate that code.
      - deathanatos 8y ago
        I'm wondering if it inlines it (and thus eliminates it). But this would come with a performance penalty: it makes the function you assert() in no longer a leaf function (it calls assert()) and AFAIK, Go only inlines leaf functions. (So, any function in which you call assert() is no longer eligible for inlining.)
        helper 8y ago
        chrchang523 is correct. In my test the caller function can still get inlined.
      - chrchang523 8y ago
        deathanatos: Go 1.12 can inline non-leaf functions, and I’d be surprised if it still fails to do the right thing here.

marvy 8y ago

To draw_down: your comments are showing up as dead, As for assert in Go... couldn't you just make a function that takes a Boolean and panics?

everdev 8y ago
You could, but then when you get an error, you'll see the file and line number of the assert function rather than the code that actually produced the error.
- bbatha 8y ago
  The runtime package allows you to grab the current trace, you can just pop the last frame off and print that.
  - everdev 8y ago
    True. The only other challenge is that in production software you rarely want to call panic()
    - IanS5 8y ago
      As another comment mentioned you can just use build tags to make assert a no-op in release builds
rabidrat 8y ago
Also, there is no way to eliminate the assert clause in a high-performance (release) build.

zaroth 8y ago

It seemed random and out of place to me. Like some sort of Wiki vandalism. Why do I care about their opinion of Go in SQLite dev docs?

smitty1e 8y ago
Whoever wrote that was probably shooting from the Hipp.
geezerjay 8y ago
> Why do I care about their opinion of Go in SQLite dev docs? Apparently some peoplr care, considering the number of comments on how Go can, does and should handle this usecase.