Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Learn C in 2023?

news.ycombinator.com

Post reply on HN
Print view View original

211–220 of 220 posts

Re: Ask HN: Learn C in 2023?

#211

Post by [deleted] »

woodruffw wrote: post #206
torstenvl wrote: post #205

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?

#212

Post by woodruffw »

shrimp_emoji wrote: post #210
woodruffw wrote: post #206

Earlier quoted context omitted.

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.

"Worse is Better" isn't meant to be derogatory: it's the term of art used by the Unix world to describe Unix and C's own adoption arc[1].

[1]: https://cs.stanford.edu/people/eroberts/cs201/projects/2010-...

Re: Ask HN: Learn C in 2023?

#213

Post by mustache_kimono »

torstenvl wrote: post #209
mustache_kimono wrote: post #166

Earlier quoted context omitted.

> 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.

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

I think you mean the Rust trademark, and sorry, but you don't get to use IBM or Google's mark willy-nilly either? I'm not sure it's a realistic expectation on your part to be able to market your changes under the other guy's mark.

Re: Ask HN: Learn C in 2023?

#214

Post by mustache_kimono »

torstenvl wrote: post #205
woodruffw wrote: post #201

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…

> If a competitor ever did arise, patenting the borrow checker mechanism would be all it would take to completely crush them.

Apache 2 includes a patent grant? So I think most of this comment is clearly erroneous.

Re: Ask HN: Learn C in 2023?

#215

Post by brezelgoring »

baby wrote: post #138
brezelgoring wrote: post #104

Earlier quoted context omitted.

I've got a single digit number of contributions to projects that I like, mostly because of how daunting it is to familiarize oneself with a codebase, and this 'git log -reverse' trick seems incredible as an entry point to a new project. That being said, how do you feel about using this technique for repos with 2k+ commits? It seems unrealistic to read all of them, or am I being short-sighted here? I get demotivated j…

I'm not sure why GP's post is upvoted so much, IMO it's a bad way to learn. I would instead find an entry point, a self-contained task that doesn't touch a lot of the codebase that you can use to learn something. Then, as you get more comfortable with some part of the codebase you can expand your scope by looking at tasks that touch other things. In general reading code is 50% of the work, the other 50% is to play wi…

That sounds reasonable, and I do agree that inching forward seems like a more viable approach to contributing in FOSS.

Thanks for the answer.

Re: Ask HN: Learn C in 2023?

#216

Post by brezelgoring »

sfpotter wrote: post #114
brezelgoring wrote: post #104

Earlier quoted context omitted.

I've got a single digit number of contributions to projects that I like, mostly because of how daunting it is to familiarize oneself with a codebase, and this 'git log -reverse' trick seems incredible as an entry point to a new project. That being said, how do you feel about using this technique for repos with 2k+ commits? It seems unrealistic to read all of them, or am I being short-sighted here? I get demotivated j…

Reading 2k+ commits is a big waste of time. Forcing yourself to read every commit to a project you "like" in order contribute to it is putting the cart before the horse. Just because you "like" a project doesn't mean you will have the skills to contribute usefully to it. This isn't a bad thing. I "like" GCC, but I don't have the skills to contribute to it. I'm not losing any sleep over this, and I'm definitely not th…

I like this approach to FOSS contributions, thanks for the answer, sfpotter.

Re: Ask HN: Learn C in 2023?

#217

Post by [deleted] »

mustache_kimono wrote: post #214
torstenvl wrote: post #205

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…

> If a competitor ever did arise, patenting the borrow checker mechanism would be all it would take to completely crush them. Apache 2 includes a patent grant? So I think most of this comment is clearly erroneous.

[deleted]

Re: Ask HN: Learn C in 2023?

#218

Post by mustache_kimono »

torstenvl wrote: post #205
woodruffw wrote: post #201

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…

> 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?

1) I'm not certain the Rust Foundation actually owns the underlying patent IP for the borrow checker.

2) But granting it does, imagine, the foundation or its successors files for a patent years after including that IP in Rust and years after granting two extremely permissive licenses (MIT/Apache 2) for the use of that IP, and tries to enforce their patent rights against your fork, FeO.

3) What exactly is their hope of winning a patent infringement case after granting those extremely permissive licenses?

Don't both MIT and Apache 2 provide a very strong defense against infringement where one is using and modifying the Rust code base (you fork creating FeO)? If you don't like Apache 2's explicit patent grant, Rust of course offers you the option to use MIT's implied grant.

"Any language used by the owner of the patent, or any conduct on his part exhibited to another from which that other may properly infer that the owner consents to his use of the patent in making or using it, or selling it, upon which the other acts, constitutes a license and a defense to an action for a tort." De Forest Radio Telephone Co. v. United States, 273 US 236, 241 (1927).

Can you show me an instance where anything like what you describe has occurred? If not, you should describe precisely how your hypothetical could occur? Because, from where I sit, your theories seem like pure FUD.

Re: Ask HN: Learn C in 2023?

#219

Post by AccountAccount1 »

andreygrehov wrote: post #63

I'm not a C engineer, but I think I have an interesting recommendation to consider. Since you are already familiar with other languages, you obviously don't need to know the basics of C. The basics are the same everywhere. Instead, you'd likely want to build that mindset on how to build good software with C. I suggest you read other people's code and try to deep dive into the whys. I heard Redis is a well-written sof…

Damn, what a great comment.

Re: Ask HN: Learn C in 2023?

#220

Post by _ank_it »

andreygrehov wrote: post #63

I'm not a C engineer, but I think I have an interesting recommendation to consider. Since you are already familiar with other languages, you obviously don't need to know the basics of C. The basics are the same everywhere. Instead, you'd likely want to build that mindset on how to build good software with C. I suggest you read other people's code and try to deep dive into the whys. I heard Redis is a well-written sof…

This. But for C++ and Python.
Post reply on HN