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

Modern C [pdf]

icube-icps.unistra.fr

Post reply on HN
Print view View original

31–40 of 396 posts

Re: Modern C [pdf]

#31

Post by kbart »

Waterluvian wrote: post #15

I've had no luck learning a language on its own. But I've had a lot of luck learning languages as part of something bigger. Like C# via. Unity, Swift via. 2D game dev in XCode. Any suggestions on what I should apply C to as a way to learn it?

"Any suggestions on what I should apply C to as a way to learn it?"

If you are into hardware as well, get microcontrollers and do some home improvement projects. The easiest way is to get Raspberry Pi or similar, but if you also want to learn a great deal about system programming, try to bring up MCU on your own, starting with bootloader.

Re: Modern C [pdf]

#32

Post by burfog »

shakna wrote: post #21
qwertyuiop924 wrote: post #4

Can any C programmers evaluate this book? I don't do a lot of C, so I can't really do it. Does it advocate good best practices? Does it talk about pitfalls? Does it overemphasize new, possibly less widely implemented, features? Does it do/not do anything else we should know about?

> Does it advocate good best practices? That may come down to opinion. For example, type qualifiers are bound to the left. Traditionally you would write: char *var; They advocate keeping type on the left, name on the right, so: char* var; A few things like that are covered under "Warning to experienced C programmers". Personally, I prefer it, but have always done what everyone else expects, so there are no fights ove…

Note that var1 and var2 are not the same type:

    char* var1, var2;
Traditional style makes this clear.

Re: Modern C [pdf]

#33

Post by [deleted] »

solidsnack9000 wrote: post #25
SwellJoe wrote: post #9

It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing? I mean, is there some subset of C that is safer than what I think of when I think of C? I know about stuff like reference counting techniques, rather than manual memory management, for example, and that goes miles towards safer coding. But, even so, the variety of ways you can shoot yourself in the f…

> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? While Rust might be feasible, Go can't really provide libraries like SQLite: Go's C compatibility story is disappointing and awkward.

[deleted]

Re: Modern C [pdf]

#34

Post by majewsky »

slededit wrote: post #22
Waterluvian wrote: post #20

Earlier quoted context omitted.

Hmmm... Yes I'll have to give it some thought. I use Python for most of my scripting needs. I guess I've never had a need that's required better performance.

Even though it may not make technical sense to choose C, you may want to just use it to learn.

That's exactly why I wrote https://github.com/majewsky/xmpp-bridge in C. It feels so different to me to program in C than, say, Go or Python. I become so much more mindful of every step that I take.

Re: Modern C [pdf]

#35

Post by im3w1l »

mitchty wrote: post #29
solidsnack9000 wrote: post #24

Earlier quoted context omitted.

Rust is more focused on C compatibility and simple (dumb) operational semantics than Idris and other dependently typed languages. Rust will never require GC, for example; maybe Idris doesn't now but is that a focus for them?

Idris can compile to c, it requires no runtime. You're probably thinking of Haskell with its RTS. Idris is closer to ocaml in that regard. I cough may have already tried using idris in a kernel module. (for fun, not for serious)

And how did it go?

Re: Modern C [pdf]

#36

Post by SQLite »

SwellJoe wrote: post #9

It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing? I mean, is there some subset of C that is safer than what I think of when I think of C? I know about stuff like reference counting techniques, rather than manual memory management, for example, and that goes miles towards safer coding. But, even so, the variety of ways you can shoot yourself in the f…

Go has chosen to omit assert(), because assert() is frequently misused they say. Antibiotics are also frequently misused, but that is not a good reason to prohibit them. The omission of assert() makes Go a non-starter.

Rust seems more promising, but it is still not to the point where I am interested in rewriting SQLite in Rust, though I may revisit this decision in future years.

Some current reasons to continue to prefer C over Rust:

(1) Rust is new and shiny and evolving. For a long-term project like SQLite, we want old and boring and static.

(2) As far as I know, there is still just a single reference implementation of rustc. I'd like to see two or more independent implementations.

(3) Rust's ever-tightening interdependence with Cargo and Git is disappointing.

(4) While improving, Rust still needs better tooling for things like coverage analysis.

(5) Rust has "immutable variables". Seriously? How can an object be both variable and immutable? I realize this is just an unfortunate choice of terminology and not a fundamental flaw in the language, but I believe details like this need to be worked out before Rust is considered "mature".

Re: Modern C [pdf]

#38

Post by pjmlp »

mitchty wrote: post #12
cygx wrote: post #10

Earlier quoted context omitted.

Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? Note that Go does not entirely compete in the same space, and Rust is only starting to gain traction.

Also if anyone is talking about systems programming, it would be beneficial if you specify what that means. I've seen people consider "systems" programming as relating to building web services. Traditionally systems programming would be more kernel level and utilities/daemons. Rust might be OK to start using for the latter, but its very much not yet where I'd start using it for new things for either of the traditiona…

Which is why I am more willing to bet on Swift and .NET Native getting more widely used than Rust.

Not to misrepresent the work the Rust guys are doing, it is great what they are doing and I have lots of fun dabbling on it.

But new system programming programming languages tend to be adopted when an OS vendor tells devs, either use it or go code elsewhere.

On OSes that have significant market share, devs tend to learn the new language instead of waving it away.

Re: Modern C [pdf]

#39

Post by CmdrSprinkles »

SwellJoe wrote: post #9

It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing? I mean, is there some subset of C that is safer than what I think of when I think of C? I know about stuff like reference counting techniques, rather than manual memory management, for example, and that goes miles towards safer coding. But, even so, the variety of ways you can shoot yourself in the f…

> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go?

From a professional standpoint, you might as well be asking if I have infinite money and time. Nothing happens in a vacuum

But ignoring that, I would say, for me, it boils down to:

1. How important is performance? Is this a case where all that really matter is that it works? That I have a decent algorithm? Or am I going to be doing "real" optimization, even if only for a single platform? Even at just the "is my algorithm good?" stage I would lean toward C/C++ for systems work.

2. And this is the important one: Do I need this code to exist and be usable in one year? Five? Ten? Stuff like Rust might be fine for the one year frame, but for even as few as five I am going to want something established that I know will have support. And that means C/C++ for systems development (python, ruby, and js for scripting, and so forth).

Re: Modern C [pdf]

#40

Post by pjmlp »

cygx wrote: post #10
SwellJoe wrote: post #9

It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing? I mean, is there some subset of C that is safer than what I think of when I think of C? I know about stuff like reference counting techniques, rather than manual memory management, for example, and that goes miles towards safer coding. But, even so, the variety of ways you can shoot yourself in the f…

Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? Note that Go does not entirely compete in the same space, and Rust is only starting to gain traction.

Given that Go is quite similar to Oberon, I don't fully agree.

http://www.projectoberon.com/

http://people.inf.ethz.ch/wirth/ProjectOberon/index.html

http://www.astrobe.com/default.htm

http://wiki.osdev.org/Go_Bare_Bones

It just needs someone to port that Oberon code to Go, maybe people will then stop discussing how suitable Go is for systems programming.

Post reply on HN