5 ms·

> at which point many of the readers got bored I don’t know Go or Rust, and yes, I did almost get bored and quit the article. However... glad I powered throug

> at which point many of the readers got bored I don’t know Go or Rust, and yes, I did almost get bored and quit the article. However... glad I powered through because the 169 dependency packages that ended up bringing in GRPC and this Protobuffers and the kitchen sink was worth the read. In a 0.00% acceptable conclusion. The language shouldn’t encourage this imo. I get the idea. But I’m coming from embedded so when I see they have a 32bit argument with 4.29 billion options to represent a boolean, well, no sir I can’t get behind that at all :) Likewise I think the author would have been well to leave Rust out of it most of the time. Your gripes with x should be independent of “y lang does it better” aside from just knowing it is possible to be better.

bluejekyll 7y ago
> the author would have been well to leave Rust out of it most of the time. Initially I thought the same, but then I realized that it was being used as a means of expressing that it doesn’t have to be this way. That there are better choices, and here’s an example of better choices. Probably too much detail on the Rust, but using it to contrast with some of the poor decisions pointed out in Go is useful.
- nonbirithm 7y ago
  Is there a language besides Rust that could be used instead as this example? As in, languages whose standard library was so carefully designed from previous experience that the design of features like Permissions/PermissionsExt and OsString deliberately take into account the design of both Windows and Unix-like internals. The author mentioned part of the reason the filesystem API is so awkward in Go is because Go was designed from the start with Unix paradigms and Windows was not even considered because there was no reason to at the time - it started as a language internal to Google and their development priorities likely excluded Windows. When it became public and more widely used Windows support became a necessity for cross platform support, but there was no going back to redesign everything so it had to be bolted on within the paradigms the stdlib's interface allowed for. When it comes to the stdlib I feel you have to be extremely careful about these things and plan for Windows users ahead of time if you intend for cross platform support - and that should be a goal if it's to be widely used. I feel like Rust only accomplished what they did because they made sure to include Windows as a first-class platform in their philosophy from the start.
  - samth 7y ago
    Yes, plenty of languages do this. For example, Racket exposes permissions as bitmasks but they work portably across platforms, and Racket handles all the filename encoding issues mentioned here.
  - nwallin 7y ago
    C++17's std::filesystem is awesome. One of the benefits of C++'s minimal standard library is that when something finally does get added 20 years after it's an established technology the OS primitives have already solidified. (threads and mutexes in C++11 for another example)
    - 7532yahoogmail 7y ago
      Best back handed compliment I've seen in a while ... And right too.
    - pjmlp 7y ago
      Well threads weren't that well done, hence std::jthread. And lets not start with the whole concurrency soap opera, that might be done by C++23, and the mistakes in std::async design.
irishsultan 7y ago
> Your gripes with x should be independent of “y lang does it better” aside from just knowing it is possible to be better. And what better way to demonstrate it's possible to do better by having an example ready?
- SlowRobotAhead 7y ago
  Because you may turn anyone who would otherwise be empathetic of your gripe with their reluctance to accept your proposed solution. I’m reminded that “not every problem needs a solution”. Or at least needs one right now. I agree, in this case it made good points, but too many of them. It just didn’t need so many examples of why “Rust is better”. If you were invested in Rust or Go, this article reads differently to you than me who is invested in neither.
  - estebank 7y ago
    Them you would have to contend with people that are either not convinced it is a problem or that think a better solution can't exist.

bluejekyll 7y ago

> the author would have been well to leave Rust out of it most of the time. Initially I thought the same, but then I realized that it was being used as a means of expressing that it doesn’t have to be this way. That there are better choices, and here’s an example of better choices. Probably too much detail on the Rust, but using it to contrast with some of the poor decisions pointed out in Go is useful.

nonbirithm 7y ago
Is there a language besides Rust that could be used instead as this example? As in, languages whose standard library was so carefully designed from previous experience that the design of features like Permissions/PermissionsExt and OsString deliberately take into account the design of both Windows and Unix-like internals. The author mentioned part of the reason the filesystem API is so awkward in Go is because Go was designed from the start with Unix paradigms and Windows was not even considered because there was no reason to at the time - it started as a language internal to Google and their development priorities likely excluded Windows. When it became public and more widely used Windows support became a necessity for cross platform support, but there was no going back to redesign everything so it had to be bolted on within the paradigms the stdlib's interface allowed for. When it comes to the stdlib I feel you have to be extremely careful about these things and plan for Windows users ahead of time if you intend for cross platform support - and that should be a goal if it's to be widely used. I feel like Rust only accomplished what they did because they made sure to include Windows as a first-class platform in their philosophy from the start.
- samth 7y ago
  Yes, plenty of languages do this. For example, Racket exposes permissions as bitmasks but they work portably across platforms, and Racket handles all the filename encoding issues mentioned here.
- nwallin 7y ago
  C++17's std::filesystem is awesome. One of the benefits of C++'s minimal standard library is that when something finally does get added 20 years after it's an established technology the OS primitives have already solidified. (threads and mutexes in C++11 for another example)
  - 7532yahoogmail 7y ago
    Best back handed compliment I've seen in a while ... And right too.
  - pjmlp 7y ago
    Well threads weren't that well done, hence std::jthread. And lets not start with the whole concurrency soap opera, that might be done by C++23, and the mistakes in std::async design.

irishsultan 7y ago

> Your gripes with x should be independent of “y lang does it better” aside from just knowing it is possible to be better. And what better way to demonstrate it's possible to do better by having an example ready?

SlowRobotAhead 7y ago
Because you may turn anyone who would otherwise be empathetic of your gripe with their reluctance to accept your proposed solution. I’m reminded that “not every problem needs a solution”. Or at least needs one right now. I agree, in this case it made good points, but too many of them. It just didn’t need so many examples of why “Rust is better”. If you were invested in Rust or Go, this article reads differently to you than me who is invested in neither.
- estebank 7y ago
  Them you would have to contend with people that are either not convinced it is a problem or that think a better solution can't exist.