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

Two types of C programmers

utcc.utoronto.ca

Post reply on HN
Print view View original

181–190 of 225 posts

Re: Two types of C programmers

#181

Post by gavinhoward »

tialaramex wrote: post #172
gavinhoward wrote: post #169

Earlier quoted context omitted.

Well, sure, but that's true of any language.

Nope, when I write tests in my Rust the out of box cargo test will check those tests pass. If I wrote inline Markdown documentation for part of the Rust code with an example, cargo test will try to build my example, and check it works - not much good having a purported "example" which doesn't even work, is it? And yet many languages don't do this.

You said fuzzing and exercising error conditions. Rust's tooling does not do that. You need something to generate those tests.

Fuzzing is still not part of the default Rust tooling.

Re: Two types of C programmers

#182

Post by gavinhoward »

GoblinSlayer wrote: post #177
gavinhoward wrote: post #82

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/wh…

>I have special array types that I use instead of straight pointers, and those arrays store their bounds. You cheat. You don't write C the hard way. But ok, that's an easier way to use C today.

Okay? I mean, I have the discipline to admit I need to do that and the discipline to actually do it.

I'm okay with cheating if it reduces bugs.

Re: Two types of C programmers

#183

Post by xorvoid »

I switch between both depending on my mood and the particular application.

For me: Rust killed C++ but not C

I have an on-again off-again love affair with C. And in its domain it’s still unmatched: low-level close to hardware where you directly need to deal with concepts that are normal abstracted away: alignment, custom layouts, type punning, pointer tagging, different types of memory, cache coherency, DMA, kernel bypass, etc etc

Sure you can do it in rust unsafe but it’s (intentionally) a world of pain.

But, when you start needing bigger abstractions or you work with a team larger than say 5, C falls on its face super fast.

But it Feels Oh So Nice otherwise.

Here’s to me hoping Rust unsafe becomes more usable and can be a proper C successor someday. But.. I’m happy to be rid of C++ :-)

(I’ve been meaning to write a blog post on this for some time)

Re: Two types of C programmers

#184

Post by xorvoid »

xorvoid wrote: post #183

I switch between both depending on my mood and the particular application. For me: Rust killed C++ but not C I have an on-again off-again love affair with C. And in its domain it’s still unmatched: low-level close to hardware where you directly need to deal with concepts that are normal abstracted away: alignment, custom layouts, type punning, pointer tagging, different types of memory, cache coherency, DMA, kernel b…

One more thing: codegen

Getting good codegen out of Rust is 5 times harder than C. And sometimes it’s not really possible.

Re: Two types of C programmers

#185

Post by GoblinSlayer »

tialaramex wrote: post #172
gavinhoward wrote: post #169

Earlier quoted context omitted.

Well, sure, but that's true of any language.

Nope, when I write tests in my Rust the out of box cargo test will check those tests pass. If I wrote inline Markdown documentation for part of the Rust code with an example, cargo test will try to build my example, and check it works - not much good having a purported "example" which doesn't even work, is it? And yet many languages don't do this.

Mere existence of a test runner is infinitesimal compared to your proposed careful testing. Saying this as someone who wrote my own test runner, it's a few lines of code.

Re: Two types of C programmers

#186

Post by jenadine »

sparkie wrote: post #69
humanrebar wrote: post #58

Earlier quoted context omitted.

> Obviously there is C++ which can leverage most of this too, but C++ traps you into an ABI which is difficult to use from any language which is not C++. To be fair to C++, all the other languages in this space are as bad at providing ABIs in their own languages. All (almost?) mostly provide ways to declare C ABIs, which C++ also supports. C++ has rough C++ ABIs, but mostly because it bothers to try in the first plac…

C's ABI is that much simpler because it doesn't really place any constraints on the memory layout of your types. With C++ (and others), the values passed around may also have vtables linked to them, so your language must then also provide an in-memory representation of objects which is compatible with the C++ representation in order to do FFI method calls. That places quite a constraint on your language because to do…

Of course the C ABI places constraints on the memory layout of the types. For example, alignment. Also in what register "small" types are passed when passing them to functions. It actually depends if the struct has float members or not. C itself is quite complex already. C++ adds more features.

But for example, the Rust ABI uses the C++ ABI, because C is too simple and doesn't support unwinding (for panics) or 128bit integers

Re: Two types of C programmers

#187

Post by jenadine »

infamouscow wrote: post #175
jenadine wrote: post #63

Earlier quoted context omitted.

What does the trademark policy has to do with this? Btw the recent fuzz recently was about some proposal and not the actual one. This is the policy: https://foundation.rust-lang.org/policies/logo-policy-and-me... and I don't see any deal breaker.

The use of trademark enforcement to coerce conferences into certain policies (which might contradict local law) is a deal breaker. It also demonstrates a willingness of the foundation to use wield power for purposes completely unrelated to the language.

There is no such things about forcing policies for conferences in the current trademark policy. (You're getting confused with a proposal that is being re-worked)

And even if there was it's hardly a deal breaker to use the language.

Re: Two types of C programmers

#188

Post by throwawaymaths »

gavinhoward wrote: post #179
throwawaymaths wrote: post #171

Earlier quoted context omitted.

sure, a sync function and an async function get compiled to two different things under the hood, but IMO colored/uncolored is about ux, not what happens under the hood. In go, or erlang, which don't have async coloring, you don't actually care what the system does under the hood. More generically, if a system takes a private function and can choose to inline it, you probably wouldn't moan that under the hood it's doi…

It can't be addressed at compile time. That's the whole point of the uncomputability of the Halting Problem. The Zig compiler would have to have perfect knowledge of all functions that can be called anywhere. At compile time. Alan Turing proved that this is impossible. In other words, Zig cannot address it. Ever.

Ok? The universe of all code that can be created by the zig compiler is strictly bounded for any given project at any given time, the halting problem does not apply. At worst, you can do an exhaustive search. The context that you're running the code in can ultimately be known, and the pointer can be set to the appropriate version based on calling context.

Re: Two types of C programmers

#189

Post by infamouscow »

jenadine wrote: post #187
infamouscow wrote: post #175

Earlier quoted context omitted.

The use of trademark enforcement to coerce conferences into certain policies (which might contradict local law) is a deal breaker. It also demonstrates a willingness of the foundation to use wield power for purposes completely unrelated to the language.

There is no such things about forcing policies for conferences in the current trademark policy. (You're getting confused with a proposal that is being re-worked) And even if there was it's hardly a deal breaker to use the language.

The proposed policy, which is clearly political in nature, has resulted in our firm decision not to adopt the crab language for our projects. Although Rust™ offers valuable features, introducing politics into the equation was both unnecessary and has caused a rift that may prove difficult to mend.

Re: Two types of C programmers

#190

Post by gavinhoward »

throwawaymaths wrote: post #188
gavinhoward wrote: post #179

Earlier quoted context omitted.

It can't be addressed at compile time. That's the whole point of the uncomputability of the Halting Problem. The Zig compiler would have to have perfect knowledge of all functions that can be called anywhere. At compile time. Alan Turing proved that this is impossible. In other words, Zig cannot address it. Ever.

Ok? The universe of all code that can be created by the zig compiler is strictly bounded for any given project at any given time, the halting problem does not apply. At worst, you can do an exhaustive search. The context that you're running the code in can ultimately be known, and the pointer can be set to the appropriate version based on calling context.

No, you can't do an exhaustive search.

Say you're a library author. You distribute pre-built library files.

You've already lost because the compiler does not know your clients' code when it compiles your library.

I am not kidding when I say it's provably impossible.

Post reply on HN