5 ms·

Rust's approach is definitely safer, but my point is that the concerns are overblown. The Go compiler raise an error if a variable (error) goes unused, and just

by nmilo 4y ago

Rust's approach is definitely safer, but my point is that the concerns are overblown. The Go compiler raise an error if a variable (error) goes unused, and just ignoring this error by naming it "_" is obviously dangerous. Yes, Rust makes it easier to never ignore an error, but I don't think I've ever accidentally ignored an error that I shouldn't have in Go.

jhoechtl 4y ago
Golang gives you freedom. Rust gives you seat belts. It depends on you what you value more.
- jeroenhd 4y ago
  I don't think Go gives you freedom, actually. There aren't any good standard library functions for dealing with badly encoded unicode for file names, for example. Instead, Go provides what the language designers considered solutions to most problems. Window not having Unix permissions? Just fake a bunch of them. Path not valid unicode? Probably not a problem. As long ad you agree with the way the Go designers think, that'll save you tons of work. Just don't use Go in situations where those solutions might not work out, like when you're iterating over arbitrary files instead of the files you've created yourself in Go code.
  - shadowgovt 4y ago
    The counterpoint is "your filenames shouldn't be badly-encoded unicode." In other words, "If `ls` can't render it, it's a bad filename. Rename the file." (This does mean that Go is constraining the set of problems it's easy to solve with it. But that's the nature of programming in general... We decide what problems need to be easier to solve at the expense of putting some problems outside the "sweet spot" and requiring more work to solve them).
    - WJW 4y ago
      If `ls` can't render a filename that is legal under the POSIX specs, there are two possibilities: - `ls` is wrong and should be fixed. - The specs are wrong and should not allow filenames to be arbitrary bytesequences. The third option ("The user is wrong even though they did exactly what was in the spec") is just unsatisfactory because it self-contradicts.
      - shadowgovt 4y ago
        Specs are a three-edged sword: the spec, the intent, and the implementation. And "The user is wrong even though they did exactly what was in the spec" is pretty much the rule, not the exception.
- asherah 4y ago
  would highly prefer my car to have seatbelts over "simplicity" and "freedom" if i plan to go over 30mph with it
  - astrange 4y ago
    Personally I like my programming languages to have warnings instead of errors for something like an unused import. To avoid the car analogy, let's use construction - an in construction building should be allowed to keep the scaffolding up while it's being built. But maybe you should still clean the floors? Uh oh, it's getting away from me already.
- isubasinghe 4y ago
  I would argue Golang is the most restrictive because it doesn't have an escape hatch from its language features. Rust will get out of your way if you really want it to. It just gives you a seat belt because you are on the highway (writing systems code) but you are free to take it off.
- masklinn 4y ago
  Yes nothing says "the language gives you freedom" like an unused import being a non-bypassable compilation error.
HL33tibCe7 4y ago
> Go compiler raise an error if a variable (error) goes unused It doesn't though. It's not a warning or error to not use the return value of a function that only returns an error, for instance (https://go.dev/play/p/se6-zHHVezH https://go.dev/play/p/se6-zHHVezH). There are static error checking tools you can use like https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck to work around this, but most people don't use them. I've run into a lack of Go error checking many times. Many times it's just the trivial case, where the compiler doesn't warn about not checking the result of an error-returning function. But often it'll be subtler, and the result of Go's API design. One example is its file writing API, which requires you to close the file and check its error to be correct. Many times people will just `defer file.Close()`, but that isn't good enough - you're ignoring the error there. Worse still is e.g: writing to a file through a bufio.Writer. To be correct, you need to remember to flush the writer, check that error, then close the file and check that error. There's no type-level support to make sure you do that.
- jeroenhd 4y ago
  Rust will allow you to ignore a Result as well, to be fair, though with a compile time warning. I don't think I know any language that'll throw a compiler error at you if you ignore the return value of a function that indicates success or failure.
  - steveklabnik 4y ago
    Languages with "linear types" would, but there aren't any mainstream ones. (And, to be extra clear, it only lets you ignore a Result if you don't care about the Ok value, if you want to use it, it does not.)
- masklinn 4y ago
  > It doesn't though. It's not a warning or error to not use the return value of a function that only returns an error, for instance (https://go.dev/play/p/se6-zHHVezH https://go.dev/play/p/se6-zHHVezH). An other issue which is as big or bigger is that Go only tracks variables, it doesn't track reads and writes (unlike... well rust for starters). So the compiler will also be perfectly happy if you call two erroring function, check the first's error but then reassign the second's error to the same variable (say, err, because it's always the variable for the error) and... completely forget to check it: https://go.dev/play/p/GJiovZwvHqj https://go.dev/play/p/GJiovZwvHqj I think errcheck also checks for it, but as you say it's not part of the language and its use is not ubiquitous.

by nmilo 4y ago

jhoechtl 4y ago

Golang gives you freedom. Rust gives you seat belts. It depends on you what you value more.

jeroenhd 4y ago
I don't think Go gives you freedom, actually. There aren't any good standard library functions for dealing with badly encoded unicode for file names, for example. Instead, Go provides what the language designers considered solutions to most problems. Window not having Unix permissions? Just fake a bunch of them. Path not valid unicode? Probably not a problem. As long ad you agree with the way the Go designers think, that'll save you tons of work. Just don't use Go in situations where those solutions might not work out, like when you're iterating over arbitrary files instead of the files you've created yourself in Go code.
- shadowgovt 4y ago
  The counterpoint is "your filenames shouldn't be badly-encoded unicode." In other words, "If `ls` can't render it, it's a bad filename. Rename the file." (This does mean that Go is constraining the set of problems it's easy to solve with it. But that's the nature of programming in general... We decide what problems need to be easier to solve at the expense of putting some problems outside the "sweet spot" and requiring more work to solve them).
  - WJW 4y ago
    If `ls` can't render a filename that is legal under the POSIX specs, there are two possibilities: - `ls` is wrong and should be fixed. - The specs are wrong and should not allow filenames to be arbitrary bytesequences. The third option ("The user is wrong even though they did exactly what was in the spec") is just unsatisfactory because it self-contradicts.
    - shadowgovt 4y ago
      Specs are a three-edged sword: the spec, the intent, and the implementation. And "The user is wrong even though they did exactly what was in the spec" is pretty much the rule, not the exception.
asherah 4y ago
would highly prefer my car to have seatbelts over "simplicity" and "freedom" if i plan to go over 30mph with it
- astrange 4y ago
  Personally I like my programming languages to have warnings instead of errors for something like an unused import. To avoid the car analogy, let's use construction - an in construction building should be allowed to keep the scaffolding up while it's being built. But maybe you should still clean the floors? Uh oh, it's getting away from me already.
isubasinghe 4y ago
I would argue Golang is the most restrictive because it doesn't have an escape hatch from its language features. Rust will get out of your way if you really want it to. It just gives you a seat belt because you are on the highway (writing systems code) but you are free to take it off.
masklinn 4y ago
Yes nothing says "the language gives you freedom" like an unused import being a non-bypassable compilation error.

HL33tibCe7 4y ago

> Go compiler raise an error if a variable (error) goes unused It doesn't though. It's not a warning or error to not use the return value of a function that only returns an error, for instance (https://go.dev/play/p/se6-zHHVezH https://go.dev/play/p/se6-zHHVezH). There are static error checking tools you can use like https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck to work around this, but most people don't use them. I've run into a lack of Go error checking many times. Many times it's just the trivial case, where the compiler doesn't warn about not checking the result of an error-returning function. But often it'll be subtler, and the result of Go's API design. One example is its file writing API, which requires you to close the file and check its error to be correct. Many times people will just `defer file.Close()`, but that isn't good enough - you're ignoring the error there. Worse still is e.g: writing to a file through a bufio.Writer. To be correct, you need to remember to flush the writer, check that error, then close the file and check that error. There's no type-level support to make sure you do that.

jeroenhd 4y ago
Rust will allow you to ignore a Result as well, to be fair, though with a compile time warning. I don't think I know any language that'll throw a compiler error at you if you ignore the return value of a function that indicates success or failure.
- steveklabnik 4y ago
  Languages with "linear types" would, but there aren't any mainstream ones. (And, to be extra clear, it only lets you ignore a Result if you don't care about the Ok value, if you want to use it, it does not.)
masklinn 4y ago
> It doesn't though. It's not a warning or error to not use the return value of a function that only returns an error, for instance (https://go.dev/play/p/se6-zHHVezH https://go.dev/play/p/se6-zHHVezH). An other issue which is as big or bigger is that Go only tracks variables, it doesn't track reads and writes (unlike... well rust for starters). So the compiler will also be perfectly happy if you call two erroring function, check the first's error but then reassign the second's error to the same variable (say, err, because it's always the variable for the error) and... completely forget to check it: https://go.dev/play/p/GJiovZwvHqj https://go.dev/play/p/GJiovZwvHqj I think errcheck also checks for it, but as you say it's not part of the language and its use is not ubiquitous.