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

The case against a C alternative

c3.handmade.network

Post reply on HN
Print view View original

301–310 of 388 posts

Re: The case against a C alternative

#301

Post by dwattttt »

bluGill wrote: post #297
smitty1e wrote: post #215

Earlier quoted context omitted.

One cannot imagine C++ failing to emulate Rust's borrow checker by the end of the decade, even if compiler support is required. Has C++ ever failed to snarf a feature?

Many on the C++ committee are interested in the borrow checking, but are not sure how to make it work in C++. The hard part is they cannot break compatibility with code that is legal with previous versions of C++. If there is even one pathological case where the borrow checker will reject code that doesn't have a memory leak then they will not accept it, and require whoever proposes this borrow checker to prove the a…

Box::leak. Assuming the object you're leaking contains no references, it can then live for 'static (the lifetime of the process)

Re: The case against a C alternative

#302

Post by Ygg2 »

proto_lambda wrote: post #287
tialaramex wrote: post #273

Earlier quoted context omitted.

Rust's assumption is that it's the compiler's job to reject all wrong programs (usually with a helpful diagnostic). In C++ the assumption is that it's the compiler's job to permit all correct programs. You obviously ideally want both, but that's not actually possible when you have a language this powerful. So, Rest's choice means sometimes (more rarely these days but it can happen) you will write a program that is co…

To expand on your float sorting example, sorting a slice[1] in Rust requires the element type to implement the Ord trait, i.e. be totally ordered. Trying to sort a slice of floats will result in a compiler error, even though it might be totally fine as long as all your floats are "ordinary". Instead, to sort a slice of floats, you have to explicitly specify what would happen for the non-ordinary cases; e.g. by using…

So rather than introducing a hard to detect bug (with NaN, Inf, -Inf), Rust makes me think about it and not just let whoever worked on compiler decide.

How is this a negative? I'd rather program fail at compile than runtime, and rather it fail loudly than quietly.

Also Rust doesn't prevent you from making optimal ordering, just a tinge more verbose.

Re: The case against a C alternative

#303

Post by WalterBright »

jstimpfle wrote: post #232
WalterBright wrote: post #178

Earlier quoted context omitted.

C has a huge performance burden from 0 terminated strings. Programs are constantly running strlen() or equivalent to get the length. Length-delineated strings, like what D has, are an order of magnitude faster.

_There are_ programs that are constantly running strlen(). C strings are the default builtin string representation that has an acceptable tradeoff for performance vs space and simplicity for where they are used: Mostly in string literals, which are expected to be small strings. Mostly for printf() and friends. Zero-terminated strings are space efficient and don't allow bike shedding like length-prefixed strings do. A…

> that has an acceptable tradeoff for performance vs space and simplicity for where they are used

Is it? I've been programming strings for 45 years now. Including on 8 and 10 bit machines. All that space efficiency goes out the window when one wants a subset of a string that isn't a common tail.

The simplicity goes out the window as soon as you want a substring that isn't a common tail. Now you have memory allocation to deal with.

The performance goes out the window because now the entire string contents has to be loaded into the cache to determine its length.

> length-prefixed

Are worse. Which is why I didn't mention them.

> Sane programs use store length

Meaning they become length-delineated programs, except it's done manually, tediously, and error-prone.

Whenever I review C code, the first thing I look at are the strlen/strncpy/str** sequences. It's almost always got a bug in it, an off-by-one error.

Re: The case against a C alternative

#304

Post by selfmodruntime »

tpoacher wrote: post #298

After many years in this field, I am convinced we don't need a better "C" at all. We need better "C education".

I tend to disagree at this notion. I've used C for almost a decade now and I've seen many developers who were far more talented than me make similar mistakes all the time.

Some problems require solutions which are unable to be solved in C in a safe way.

Re: The case against a C alternative

#305

Post by amaranth »

elihu wrote: post #141
dist1ll wrote: post #83

Earlier quoted context omitted.

This is why I hope unikernels & Rust will eventually replace docker & linux for high-performance, high-security production deployments.

I agree. I think of address space context switching overhead as the performance price we pay for not being able to run all our programs in a single address space, which we could safely do if we knew all the programs were emitted by a trusted compiler that disallows unsafe memory access. Imagine if system calls were just ordinary functions that can be called with no more than the normal function call overhead? What if…

This is what Microsoft Research's Singularity OS did, with the language being C#. Their argument was that the MMU's address space isolation was a 30% Unsafe Code Tax so even if C# was slower than C if they could get the slowdown to less than that it was still an overall performance win.

I'm pretty sure the discovery of Meltdown/Spectre and similar speculative execution attacks would completely wreck this model. The fix for those exploits has been to make the isolation barriers even stronger but if you don't have them at all you're wide open. If you had such an OS but then had to split it back into separate address spaces you've now lost the performance gains and just have a slower OS that is harder to develop drivers for.

Re: The case against a C alternative

#306

Post by dmux »

sicp-enjoyer wrote: post #102
xyzsparetimexyz wrote: post #23

You could write a 100-line python script that compiles from your custom language to C code and it's still be better than C. There's lots of ways to re-use existing tooling and the bar really isn't that high for better languages

Why do you think more of these projects don't take this approach? I would be 10x more likely to try one in a professional setting if I knew the portion I was taking chance on was source translation layer, and I could rely on the well tested and supported C infrastructure.

The Nim language compiles Nim source code into C as an intermediate step.

Re: The case against a C alternative

#307

Post by proto_lambda »

Ygg2 wrote: post #302
proto_lambda wrote: post #287

Earlier quoted context omitted.

To expand on your float sorting example, sorting a slice[1] in Rust requires the element type to implement the Ord trait, i.e. be totally ordered. Trying to sort a slice of floats will result in a compiler error, even though it might be totally fine as long as all your floats are "ordinary". Instead, to sort a slice of floats, you have to explicitly specify what would happen for the non-ordinary cases; e.g. by using…

So rather than introducing a hard to detect bug (with NaN, Inf, -Inf), Rust makes me think about it and not just let whoever worked on compiler decide. How is this a negative? I'd rather program fail at compile than runtime, and rather it fail loudly than quietly. Also Rust doesn't prevent you from making optimal ordering, just a tinge more verbose.

> I'd rather program fail at compile than runtime, and rather it fail loudly than quietly.

I agree! I was just illustrating the kind of tradeoff that has to be made for that to be possible.

Re: The case against a C alternative

#308

Post by account42 »

bregma wrote: post #240
jstimpfle wrote: post #225

Earlier quoted context omitted.

unique_ptr is pretty bad for performance as well. It is more complicated to use compared to raw pointers and encourages an OOP object-per-object piecemal code and data architecture. I've never seen a C++ program making use of unique_ptr that didn't give a strong smell of enterprise programming.

Use correctly std::unique_ptr has no measurable impact on performance compared with the equivalent non-smart-pointer code. You use std::unique_ptr to indicate ownership, and pass raw pointers around to indicate non-ownership. That approach has the strong smell of a good programmer using the right tool for the job, especially considering the job is to communicate intent to the future reader. It's like the classic argu…

> Use correctly std::unique_ptr has no measurable impact on performance compared with the equivalent non-smart-pointer code.

One wart of unique_ptr (and other smart pointers) is that it cannot be passed in a register when used as a function parameter, at least with the System V ABI used on Linux.

Also, the caller is responsible for destruction and there is no way to specify that a function always "consumes" a unique_ptr so the compiler cannot eliminate the destructor code: https://godbolt.org/z/sz79GoETv

Of course if the compiler can inline the call or at least controls both and can clone the function with a custom calling convention then that doesn't have to be a problem. But it still sucks that even something as seemingly simple as a tiny wrapper around a pointer does come with a cost.

Re: The case against a C alternative

#309

Post by anonymoushn »

bregma wrote: post #240
jstimpfle wrote: post #225

Earlier quoted context omitted.

unique_ptr is pretty bad for performance as well. It is more complicated to use compared to raw pointers and encourages an OOP object-per-object piecemal code and data architecture. I've never seen a C++ program making use of unique_ptr that didn't give a strong smell of enterprise programming.

Use correctly std::unique_ptr has no measurable impact on performance compared with the equivalent non-smart-pointer code. You use std::unique_ptr to indicate ownership, and pass raw pointers around to indicate non-ownership. That approach has the strong smell of a good programmer using the right tool for the job, especially considering the job is to communicate intent to the future reader. It's like the classic argu…

Are the answers to this stackoverflow question incorrect? https://stackoverflow.com/questions/58339165/why-can-a-t-be-...

Re: The case against a C alternative

#310

Post by account42 »

camel-cdr wrote: post #241
jiggawatts wrote: post #60

Earlier quoted context omitted.

Not to mention that both C++ and Rust can specialise algorithms and containers for specific types, whereas in C most developers resort to void* and function pointers. It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language. For example, typical C programs also don't use hashtables even when this makes the most sense, causing weird performan…

"void* and function pointers" behaves essentially the same as templates, assuming the compiler inlines or function clones the function called with constant expression arguments.

All equivalent code has the same performance with a sufficiently smart compiler. In practice, compilers are often not sufficiently smart.
Post reply on HN