Live data from Hacker News

Ask HN: Learn C in 2023?

news.ycombinator.com

201–210 of 220 posts

Re: Ask HN: Learn C in 2023?

#201

Earlier quoted context omitted.

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?

> I don't even know what you're referring to with IP law. The projects' names and logos? I think it's the fact that if you took the Rust codebase and forked[1] it to accept new keywords, the resulting language that it accepts is most definitely not Rust . If you did the same to a C compiler[2], the resulting compiler would still be called a C compiler by everyone. [1] Assuming that the license allows it. [2] One who'…

Yes, the license allows it. Rust's compiler is more permissively licensed than GCC, and is roughly as permissively licensed as LLVM.

This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C. This is exactly the same as is true for Rust, except that the reference is the the living standard rather than an ISO standard.

By the original commenter's logic, the modified C compiler would effectively be proprietary: it no longer has a public, liberally licensed specification that it conforms to. But this isn't the way anybody in the open source community uses the word "proprietary," because it precludes any open-source work that doesn't have a corresponding formal specification.

Re: Ask HN: Learn C in 2023?

#202

Earlier quoted context omitted.

> I don't even know what you're referring to with IP law. The projects' names and logos? I think it's the fact that if you took the Rust codebase and forked[1] it to accept new keywords, the resulting language that it accepts is most definitely not Rust . If you did the same to a C compiler[2], the resulting compiler would still be called a C compiler by everyone. [1] Assuming that the license allows it. [2] One who'…

Yes, the license allows it. Rust's compiler is more permissively licensed than GCC, and is roughly as permissively licensed as LLVM. This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C . This is exactly the same as is true for Rust, except that the reference is the the living standard rather than an ISO standard. By the o…

> This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C.

It doesn't make sense to you, certainly.

To the type of person who've used a dozen different C compilers, all of them containing extensions to the language, and all of them still advertised as "C compilers", the argument makes perfect sense.

I mean, the input to the GCC C compiler is, by default, C with extensions, and yet even you still called it a C frontend, not a "SomeOtherLanguage" frontend.

You may not agree that the argument is valid or sound, but you can't with a straight face say that it is an unreasonable position to take.

Re: Ask HN: Learn C in 2023?

#203

Earlier quoted context omitted.

Yes, the license allows it. Rust's compiler is more permissively licensed than GCC, and is roughly as permissively licensed as LLVM. This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C . This is exactly the same as is true for Rust, except that the reference is the the living standard rather than an ISO standard. By the o…

> This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C. It doesn't make sense to you, certainly. To the type of person who've used a dozen different C compilers, all of them containing extensions to the language, and all of them still advertised as "C compilers", the argument makes perfect sense. I mean, the input to the G…

> You may not agree that the argument is valid or sound, but you can't with a straight face say that it is an unreasonable position to take.

That's not the argument I'm advancing: I'm saying it does not make sense to call that modified C compiler "proprietary."

I don't care if you call it "C" or not, because everybody who writes C understands that compiler-specific extensions are commonplace. But the existence of non-formally-specified extensions doesn't somehow override the permissively licensed nature of the compiler.

Similarly, going back to the original argument: it does not make sense to call Rust "proprietary" because it only has a living specification, rather than a formal one. It's permissively licensed, and you can modify it to your heart's content. The only reason people wouldn't call your changes "Rust" is because the community doesn't share the same expectations re: vendor extensions that C's community does.

Re: Ask HN: Learn C in 2023?

#204

Earlier quoted context omitted.

Any recommendations on static analyzers, unit tests, coverage for c? Can clang tidy give hints about modern c they way it does about modern c++?

Don't bother with this stuff (or with "modern C") if you're just beginning to learn the language. You don't need it for small programs. No one is going to yell at you if your first effort isn't perfect. And no one is going to yell at you if you read the "wrong" book, or try things out in the "wrong" order. Pick any learning resource and get started now. You'll probably get distracted and move on to something else. Co…

Do bother with this stuff, it's super helpful and helps you understand your mistakes. Writing C without using sanitizers is like playing a game on hard mode, even for simple programs (especially when you're still learning).

You may leave static analyzers for later though, since they're more likely to bother you with unimportant stuff - but not much later.

Re: Ask HN: Learn C in 2023?

#205

Earlier quoted context omitted.

> I don't even know what you're referring to with IP law. The projects' names and logos? I think it's the fact that if you took the Rust codebase and forked[1] it to accept new keywords, the resulting language that it accepts is most definitely not Rust . If you did the same to a C compiler[2], the resulting compiler would still be called a C compiler by everyone. [1] Assuming that the license allows it. [2] One who'…

Yes, the license allows it. Rust's compiler is more permissively licensed than GCC, and is roughly as permissively licensed as LLVM. This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C . This is exactly the same as is true for Rust, except that the reference is the the living standard rather than an ISO standard. By the o…

There is a difference between open software and open standards. The two are orthogonal. Open software can use closed standards (though must usually reverse-engineer them); closed software can use open standards. See, e.g., LibreOffice support for .doc files; Microsoft's TCP/IP stack. Please make an attempt to engage with intellectual honesty, and stop intentionally conflating the two.

The issue at bar is whether Rust the language is proprietary, especially as compared to C. Something is proprietary within the standard meaning of the term if it "is used, produced, or marketed under exclusive legal right of the inventor or maker." Merriam Webster, Online Edition, available at https://www.merriam-webster.com/dictionary/proprietary.

In this case, The Rust Foundation maintains and exercises exclusive legal rights over Rust that nobody exercises over C. If I make a C compiler with extensions, I can still call it C and I can still participate in C governance. C is an open standard. See https://www.open-std.org/. However, the same is not true for Rust, where governance happens entirely under the auspices of one vendor, who uses trademark law to ensure that no competitors can exist without its explicit approval. Specifically, any Rust variants other than those required for porting require explicit written permission. See https://foundation.rust-lang.org/policies/logo-policy-and-me.... Furthermore, even if I accepted my impotence in the governance process and even if I resolved to call my Rust variant something else (FeO?), competition in the market would still be chilled by The Rust Foundation's refusal to commit to fair, reasonable, and non-discriminatory (FRAND) licensing (something that is required as part of the ISO standardization process). If a competitor ever did arise, patenting the borrow checker mechanism would be all it would take to completely crush them.

I am glad that rustc is open source. I am glad that The Rust Foundation is a non-profit. I accept on faith that they want to do the right thing. However, they have deliberately created a monoculture that they enforce through IP law. Rust is proprietary, i.e., it is "something that is used, produced, or marketed under exclusive legal right of the inventor or maker." There are no open standards, there is no FRAND licensing obligation, there is no allowance for any Rust variants other than those explicitly permitted by the primary vendor of Rust compilers.

You brought up Python before, which is appropriate: Python explicitly is a "benevolent dictator for life" language. The difference with Rust is that the dictator is a legal personhood instead of a single living, breathing person. But dictatorships, even benevolent and well-intentioned ones, are ill-suited to the requirements of stability and predictability that are so vital to systems programming.

Imagine, God forbid, that The Rust Foundation goes defunct at some point in the next 100 years, and its IP bought up by the next generation's SCO or Novell or whatever, and they decide to patent the borrow checker and whatever other innovations are in Rust. Do you think that would be a bad thing?

Because it can only be bad if you agree that Rust is proprietary. If Rust were an open standard (including the borrow checker as part of the standardized compilation process and subject to mandatory FRAND licensing), then that outcome would be mitigated against.

Re: Ask HN: Learn C in 2023?

#206

Earlier quoted context omitted.

Yes, the license allows it. Rust's compiler is more permissively licensed than GCC, and is roughly as permissively licensed as LLVM. This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C . This is exactly the same as is true for Rust, except that the reference is the the living standard rather than an ISO standard. By the o…

There is a difference between open software and open standards . The two are orthogonal. Open software can use closed standards (though must usually reverse-engineer them); closed software can use open standards. See, e.g., LibreOffice support for .doc files; Microsoft's TCP/IP stack. Please make an attempt to engage with intellectual honesty, and stop intentionally conflating the two. The issue at bar is whether Rus…

This is a very large comment, filled with legitimate observations about how Rust (and most other programming language communities) choose to defend their name, logo, etc.

It has absolutely nothing to do with how "proprietary" is used in the open source community. To make it as simple as possible: if your use of the word "proprietary" includes Python and Rust but excludes Borland C, you've failed to use to word in a way that is substantive and useful to everyone else in this community.

The implied risk of Rust's trademark terms is entirely ahistorical: C did not win as a systems programming language because it satisfied FRAND or any other standard for openness. It won because Worse Is Better, in spite of onerous licensing restrictions by companies with extremely expensive and proprietary C compilers.

Re: Ask HN: Learn C in 2023?

#207

Earlier quoted context omitted.

> This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C. It doesn't make sense to you, certainly. To the type of person who've used a dozen different C compilers, all of them containing extensions to the language, and all of them still advertised as "C compilers", the argument makes perfect sense. I mean, the input to the G…

> You may not agree that the argument is valid or sound, but you can't with a straight face say that it is an unreasonable position to take. That's not the argument I'm advancing: I'm saying it does not make sense to call that modified C compiler "proprietary." I don't care if you call it "C" or not, because everybody who writes C understands that compiler-specific extensions are commonplace. But the existence of non…

> it does not make sense to call Rust "proprietary" because it only has a living specification,

It doesn't have a "living specification", it has a reference implementation. There's a difference. HTML is a living specification without a reference implementation. Rust (and many other languages) have a reference implementation without a living specification.

> The only reason people wouldn't call your changes "Rust" is because the community doesn't share the same expectations

That's not true; you cannot call it Rust because Rust, the programming language, is trademarked.

It is protected, you understand? There are legal barriers to calling your NewLanguage "Rust", as explained by the foundation themselves over here: https://foundation.rust-lang.org/policies/logo-policy-and-me...

Writing your own language and calling it Rust is legally forbidden.[1] You are, of course, free to use the permissive copyright but the name is trademarked.

Now, with C, OTOH, as an ISO standard it has no trademark so this argument does not even arise.

[1] As far as I can tell, it would be legally forbidden even if your new implementation of Rust behaves identical to the reference implementation. The best you can do is call it Rust compatible.

Re: Ask HN: Learn C in 2023?

#208

Earlier quoted context omitted.

There is a difference between open software and open standards . The two are orthogonal. Open software can use closed standards (though must usually reverse-engineer them); closed software can use open standards. See, e.g., LibreOffice support for .doc files; Microsoft's TCP/IP stack. Please make an attempt to engage with intellectual honesty, and stop intentionally conflating the two. The issue at bar is whether Rus…

This is a very large comment, filled with legitimate observations about how Rust (and most other programming language communities) choose to defend their name, logo, etc. It has absolutely nothing to do with how "proprietary" is used in the open source community. To make it as simple as possible: if your use of the word "proprietary" includes Python and Rust but excludes Borland C, you've failed to use to word in a w…

[deleted]

Re: Ask HN: Learn C in 2023?

#209

Earlier quoted context omitted.

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 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 keep using that word. It don't think you know what it means." -- Inigo Montoya This is just bizarre. If MIT/Apache-licensed Rust is proprietary, then anything could be? AFAIK there is no POSIX definition for epoll/io_uring. I suppose epoll is proprietary…

> MIT/Apache-licensed Rust

Rust is not MIT/Apache-licensed, rustc is.

Rust is licensed under terms that require explicit permission for use outside of a few very narrowly-defined circumstances.

Re: Ask HN: Learn C in 2023?

#210

Earlier quoted context omitted.

There is a difference between open software and open standards . The two are orthogonal. Open software can use closed standards (though must usually reverse-engineer them); closed software can use open standards. See, e.g., LibreOffice support for .doc files; Microsoft's TCP/IP stack. Please make an attempt to engage with intellectual honesty, and stop intentionally conflating the two. The issue at bar is whether Rus…

This is a very large comment, filled with legitimate observations about how Rust (and most other programming language communities) choose to defend their name, logo, etc. It has absolutely nothing to do with how "proprietary" is used in the open source community. To make it as simple as possible: if your use of the word "proprietary" includes Python and Rust but excludes Borland C, you've failed to use to word in a w…

>It won because Worse Is Better

I don't think this is why. I think it "won" because it was the best "high-level" language of the time and exploded to fill a huge niche, historically. In other words, historical luck.

I think that's also how JavaScript won.

Since it's always luck, and since the luckiest thing is rarely the "best" thing, it just looks like it's a selection for ironically worse quality from the outside.

Post reply on HN