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

161–170 of 220 posts

Re: Ask HN: Learn C in 2023?

#161

Post by 0xjnml »

woodruffw wrote: post #135
torstenvl wrote: post #128

Earlier quoted context omitted.

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

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,…

All commits to the Go repository must be approved by two Google employees: https://groups.google.com/g/golang-dev/c/K7oGURi0wTM/m/3mg1O...

Re: Ask HN: Learn C in 2023?

#162

Post by daniele_dll »

palmtree3000 wrote: post #157
daniele_dll wrote: post #149

Earlier quoted context omitted.

Fully agree with the principle but maybe let's not call Redis "well-written" :) Redis is a great piece of software because of how much it impacted the "evolution" of Internet not because of the code quality, Redis's code resemble spaghetti code, a lot. I will push myself and say that nowadays people would get fired for writing code like that! And before someone start to throw stones (just for the sake of it), here a…

Re: auto generated code: it saves ci time which is a pretty huge benefit. You still need to regenerate the code to make sure it's up to date, but you can do that in parallel with tests that rely on that code.

This is a valid reason, but makes sense for code bases where the generation takes tens of minutes or more not seconds.

Re: Ask HN: Learn C in 2023?

#163

Post by woodruffw »

0xjnml wrote: post #161
woodruffw wrote: post #135

Earlier quoted context omitted.

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,…

All commits to the Go repository must be approved by two Google employees: https://groups.google.com/g/golang-dev/c/K7oGURi0wTM/m/3mg1O...

Yes. Again, Google can do whatever it likes with its repositories. This is entirely unrelated to whether or not the software is proprietary.

Compare Google's practices here to Qt's[1], CMake's[2], or any other large open source project that is primarily maintained by a single company.

To be abundantly clear: I don't think this is a good way to run an open source project, but it is a legitimate way to run one. So long as the source code and standards (insofar as they exist) are themselves permissive, then the community details are just that.

[1]: https://wiki.qt.io/Qt_Contribution_Guidelines

[2]: https://github.com/Kitware/CMake/blob/master/CONTRIBUTING.rs...

Re: Ask HN: Learn C in 2023?

#164

Post by sfpotter »

daniele_dll wrote: post #160
sfpotter wrote: post #155

Earlier quoted context omitted.

Here's one example of when to commit auto-generated code: if you use a tool like Cython and want to distribute sources to an end user, it is frequently recommended to distribute the C sources generated by Cython instead of the Cython code itself. The given reason is that the end user may not have access to Cython, but will likely have access to a C compiler. (This is frequently the case on scientific clusters where u…

Importing a C file into a Python session is a practice that can ---easily--- cause ---a lot--- of headaches, the packages required to build the code as python library and make it importable will vary between systems and make it hard to debug in case of crashes. I personally would distribuite the pre-compiled binaries, CI + docker makes that much easier. The fact that "can be done" doesn't necessarely mean that "it's…

I don't agree that it's a good practice, I'm simply quoting one example to you since you mentioned you were not aware of any. IIRC, you can find many GitHub issue threads on the Cython repo where they go into more detail. It has been a while since I spent any time thinking about this so the details are no longer fresh.

Unfortunately, suggesting that users improve their runtime environment is frequently a nonstarter for different reasons. (One obvious reason: users either don't have time or technical experience to do so.)

Re: Ask HN: Learn C in 2023?

#165

Post by p1esk »

I’d probably start with learning assembly. C maps to assembly very well, and you could understand a lot of what’s happening under the hood this way.

Re: Ask HN: Learn C in 2023?

#166

Post by mustache_kimono »

torstenvl wrote: post #139
woodruffw wrote: post #135

Earlier quoted context omitted.

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,…

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

proprietary: "2: something that is used, produced, or marketed under exclusive legal right of the inventor or maker"

Can Rust be forked, modified, used/sold and distributed with your changes? If yes that hardly seems like an exclusive legal right. Your problem seems to be that people trust the Rust project, and don't trust you or a central committee (yet). But that doesn't make a project proprietary. It makes it implementation defined, which has its own problems, but those are not the same problems of as those of proprietary software.

Re: Ask HN: Learn C in 2023?

#167

Post by asveikau »

sfpotter wrote: post #159
asveikau wrote: post #131

Earlier quoted context omitted.

I've taught C at university level, and used to give crash courses to new college grads and interns in industry. The one thing I impart the most from the beginning is to develop good instincts for secure interfaces. You should be able to look at function signatures and see alarm bells for unsafe practices. For someone skilled at C this is second nature, you can see bad practices from a distance, often at the function…

It's unwise to neglect it in the long run. It's perfectly reasonable to ignore it initially. There are different valid pedagogical approaches here. Your approach may be suitable for the type of student you were interacting with, but the profile you're familiar with doesn't represent every person who might be interested in learning C.

I think a good approach is to have someone able to review code. So they can experiment and make all the common mistakes, then have feedback on it.

Re: Ask HN: Learn C in 2023?

#168

Post by queuebert »

squarefoot wrote: post #113
satvikpendem wrote: post #82

Read K&R. Yes, it's explicitly not modern C, but it enables you to think about C from a foundational level from which you can then go on to learn modern C. Build a project in C to learn how and why it works, and you'll understand how memory safe languages like Rust came about. This is what we did in college, started with C then moved on to Rust, it worked well.

What book would you suggest to someone who started with the K&R 2nd ed, then did other things, and now wants to catch up on the more modern C standards, at least the more widely supported ones?

21st Century C: https://www.oreilly.com/library/view/21st-century-c/97814493...

Re: Ask HN: Learn C in 2023?

#169

Post by gwbas1c »

tester756 wrote: post #60
gwbas1c wrote: post #58

Earlier quoted context omitted.

You'll wish you have decent C experience whenever you need to call an OS API directly; or whenever you need to write your own bindings to a library written in C. PInvoke requires a working knowledge of C's concepts; you need to know the basics about pointers and how data is represented in order to do it correctly. This statement comes from a lot of personal experience: I wrote a (currently closed source) adapter to c…

Maybe yes, but on the other hand I've never been paid for anything that used OS calls directly. The only times I've used such APIs was creating simple keylogger for tests and very simple cheat for a video game (tested on non-official servers). C# nowadays seems mostly like web backend development, tools, game scripting or automation, at least that's my perception. Anyway even if WinAPI, then why not Rust?

> Anyway even if WinAPI, then why not Rust?

Plenty of reasons:

First of all, most operating systems (and other lower-level APIs) you want to work with expose their APIs as C. These don't all have bindings in Rust. Even if you want to do them in Rust, you need to know enough C to be able to understand how to consume the API.

But then, there's plenty of legacy code in C. We aren't going to rewrite everything in Rust overnight.

More importantly, I think the "jury's still out" if Rust is better than C for embedded programming; or programming that's primarily direct memory manipulation. (And, if your embedded environment only gives you an API in C, you need to know enough C to write the API bindings for Rust before you can do embedded programming in Rust.)

Personally, I don't have any experience with unsafe Rust code. (I only do hobby projects in Rust.) In C# you can do C-style direct memory manipulation if you need to; but I'm not sure if Rust's "unsafe" is equivalent.

Re: Ask HN: Learn C in 2023?

#170

Post by suprjami »

flohofwoe wrote: post #65
suprjami wrote: post #8

https://www.learn-c.org/ If you have lots of time: https://hal.inria.fr/hal-02383654 If you can't be bothered reading a whole book: https://matt.sh/howto-c Exercises: https://www.codestepbystep.com/problem/list/c and https://exercism.org/tracks/c Once you have syntax and basic algorithms down well, watch this, the only 2 hour YouTube video I'll ever recommend: https://m.youtube.com/watch?v=443UNeGrFoM Both r/cprogram…

From the learn-c link: /* draws a point at 10, 5 */ struct point p; p.x = 10; p.y = 5; draw(p); I wish that would be a bit more 'modern', for instance: struct point p = { .x = 10, .y = 5 }; draw(p); ...or even: draw((struct point){ .x = 10, .y = 5 }); ...main reason being that this avoids any accidents with unitialized data if the struct grows (the compound literal initialization makes sure that any struct members th…

I also love designated initialisers. C99 ftw.
Post reply on HN