6 ms·

C has the unique distinction of being criticized on the one hand for the complexities of vendor-specific extensions and portability concerns... and on the other

C has the unique distinction of being criticized on the one hand for the complexities of vendor-specific extensions and portability concerns... and on the other for being insufficiently like Rust or Go, which are defined entirely by their proprietary implementations. I don't think I've ever seen this criticism leveled elsewhere. Do people criticize JavaScript programming because the ECMAScript standard doesn't give you everything you could want?

alcuadrado 4y ago
yes
woodruffw 4y ago
There is no meaningful sense in which either Rust or Go’s reference compilers is “proprietary.” If you’re trying to say that there is no ISO standard for the two, that’s an entirely different problem (and one shared by the overwhelming majority of programming languages).
- torstenvl 4y ago
  > There is no meaningful sense in which either Rust or Go’s reference compilers is “proprietary.” Nobody is talking about the compilers. This, right here — the fact that you are conflating a language and one implementation — is the whole point and is indicative of the tight control the respective organizations keep over their languages. The direction of the languages is entirely up to their private owners, and that exclusivity is enforced via intellectual property law. They are exactly as proprietary as RHEL or Unix.
  - woodruffw 4y ago
    This is not a definition of "proprietary" used anywhere in the open source community. Private direction (which Rust notably does not have) does not somehow erase the fact that both are permissively licensed and have open codebases that you can use and contribute to to your heart's content. I don't even know what you're referring to with IP law. The projects' names and logos?
    - torstenvl 4y ago
      > both are permissively licensed No, the code of the implementation is permissively licensed. Do I really have to explain, on HN of all places, the importance of distinguishing between implementation and interface?
      - woodruffw 4y ago
        This is incorrect on multiple levels: there is no organization that has "exclusive" control over Go, much less Rust. There's a company (Google) that made Go, but they have no control over the source code itself beyond the terms of the non-proprietary license they provide it under[1]. Even the things that Google does w/r/t Go are not even remotely controversial in the context of the definition of proprietary software, like CLAs. Linux has a CLA! Comparing this to Borland or Microsoft is bizarre: Microsoft and Borland actually do have proprietary C compilers that they do not make publicly available in source code form. Those compilers in turn have all kinds of non-standard, proprietary extensions. The one thing that sets C apart from Rust and Go is the presence of an official ISO standard. But this isn't material to the definition of "proprietary" in the open source world. And, well, that ISO standard is itself copyrighted. [1]: https://github.com/golang/go/blob/master/LICENSE https://github.com/golang/go/blob/master/LICENSE Edit: You shouldn't delete and re-write your comments. Here's the original comment I responded to: > That's a dubious claim, and irrelevant besides. They are proprietary, in the standard meaning of the word, because a single private organization has exclusive control over each, but whatever word you choose to describe that is up to you. > Google owns Go in a way that has never been true of Microsoft (or Borland or GNU or Apple...) when it comes to C. Edit 2: For the edited comment: you're setting up a distinction that does not matter for programming languages that do not have formal specifications. There is no "interface" to distinguish against, and the claim that Rust (or Go, or Python, or any other language without an ISO spec) is tacitly reserving all rights to the design of the language itself is completely unsubstantiated.
        torstenvl 4y ago
        Your position that not having a standard is irrelevant for languages that don't have a standard is circular and bizarre. The fact that you keep focusing on whether compilers are proprietary instead of whether Rust and Go are proprietary is starting to seem deliberately evasive. You're free to extol the virtues of open source software, and I agree with you, but it's utterly beside the point. .rs is analogous to .doc. The "right" way to handle it is defined solely with respect to the reference implementation. I view that as a problem. You may disagree, and that's fine, but don't pretend this is a conversation about something else.
  - mustache_kimono 4y ago
    > The direction of the languages is entirely up to their private owners, and that exclusivity is enforced via intellectual property law. Can't you just fork the language, or, just re Rust, participate in the RFC process? Do we need more bureaucracy?

alcuadrado 4y ago

yes

woodruffw 4y ago

There is no meaningful sense in which either Rust or Go’s reference compilers is “proprietary.” If you’re trying to say that there is no ISO standard for the two, that’s an entirely different problem (and one shared by the overwhelming majority of programming languages).

torstenvl 4y ago
> There is no meaningful sense in which either Rust or Go’s reference compilers is “proprietary.” Nobody is talking about the compilers. This, right here — the fact that you are conflating a language and one implementation — is the whole point and is indicative of the tight control the respective organizations keep over their languages. The direction of the languages is entirely up to their private owners, and that exclusivity is enforced via intellectual property law. They are exactly as proprietary as RHEL or Unix.
- woodruffw 4y ago
  This is not a definition of "proprietary" used anywhere in the open source community. Private direction (which Rust notably does not have) does not somehow erase the fact that both are permissively licensed and have open codebases that you can use and contribute to to your heart's content. I don't even know what you're referring to with IP law. The projects' names and logos?
  - torstenvl 4y ago
    > both are permissively licensed No, the code of the implementation is permissively licensed. Do I really have to explain, on HN of all places, the importance of distinguishing between implementation and interface?
    - woodruffw 4y ago
      This is incorrect on multiple levels: there is no organization that has "exclusive" control over Go, much less Rust. There's a company (Google) that made Go, but they have no control over the source code itself beyond the terms of the non-proprietary license they provide it under[1]. Even the things that Google does w/r/t Go are not even remotely controversial in the context of the definition of proprietary software, like CLAs. Linux has a CLA! Comparing this to Borland or Microsoft is bizarre: Microsoft and Borland actually do have proprietary C compilers that they do not make publicly available in source code form. Those compilers in turn have all kinds of non-standard, proprietary extensions. The one thing that sets C apart from Rust and Go is the presence of an official ISO standard. But this isn't material to the definition of "proprietary" in the open source world. And, well, that ISO standard is itself copyrighted. [1]: https://github.com/golang/go/blob/master/LICENSE https://github.com/golang/go/blob/master/LICENSE Edit: You shouldn't delete and re-write your comments. Here's the original comment I responded to: > That's a dubious claim, and irrelevant besides. They are proprietary, in the standard meaning of the word, because a single private organization has exclusive control over each, but whatever word you choose to describe that is up to you. > Google owns Go in a way that has never been true of Microsoft (or Borland or GNU or Apple...) when it comes to C. Edit 2: For the edited comment: you're setting up a distinction that does not matter for programming languages that do not have formal specifications. There is no "interface" to distinguish against, and the claim that Rust (or Go, or Python, or any other language without an ISO spec) is tacitly reserving all rights to the design of the language itself is completely unsubstantiated.
      - torstenvl 4y ago
        Your position that not having a standard is irrelevant for languages that don't have a standard is circular and bizarre. The fact that you keep focusing on whether compilers are proprietary instead of whether Rust and Go are proprietary is starting to seem deliberately evasive. You're free to extol the virtues of open source software, and I agree with you, but it's utterly beside the point. .rs is analogous to .doc. The "right" way to handle it is defined solely with respect to the reference implementation. I view that as a problem. You may disagree, and that's fine, but don't pretend this is a conversation about something else.
- mustache_kimono 4y ago
  > The direction of the languages is entirely up to their private owners, and that exclusivity is enforced via intellectual property law. Can't you just fork the language, or, just re Rust, participate in the RFC process? Do we need more bureaucracy?