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

311–320 of 388 posts

Re: The case against a C alternative

#311

Post by valepine »

Kukumber wrote: post #105

I just want: C with: - bounds checking - use after free checks - modules - sane metaprograming/template - tagged union built in without: - macro - pre declaration - split header/source That's it, no borrow checker, no weird syntax, no nothing So far D is the answser for me, but i'm worried about its future, will they keep improve the language in that direction? or will they continue with their high level stuff Zig/Ja…

Have you looked at C3 (the language OP is making)? I think it hits a lot of your boxes.

Re: The case against a C alternative

#312

Post by account42 »

afiori wrote: post #265
msla wrote: post #221

Earlier quoted context omitted.

> Please keep pushing such certifications until they become regulations that, like GDPR, even we American developers cannot ignore. People are apparently surprised at how easy it is to ignore the GDPR: https://web.archive.org/web/20200813235643/http://slawsonand... > Article 3(2), a new feature of the GDPR, creates extraterritorial jurisdiction over companies that have nothing but an internet presence in the EU and o…

The EU can fine US companies the same as it can fine most other extraterritorial companies, that is only if the other country allows it. The EU is not going to start an armed invasion over a GDPR violation. Still big multinational companies will have international branches (Google, Amazon, Microsoft, ...) that can easily be fined in their host countries.

The EU can also prevent companies from doing business in the EU if they don't follow the local laws. No need for an armed invasion if the EU can block all transfers from EU banks for anything related to your company.

Re: The case against a C alternative

#313

Post by bowsamic »

Qem wrote: post #268
bowsamic wrote: post #200

Earlier quoted context omitted.

Really? Wikipedia says it is historically uncommon EDIT: What language uses base-60??

Babylonians used it. That's the origin of our time counting system of hours, minutes and seconds and our angle measuring system of degrees, minutes and seconds. Anyway, if we someday change our number system away from 10, I hope the change will be towards a smaller base, like 8 or 6, because when one is a child, it sucks to learn the times tables. Base 12 would increase the number of entries by 44%. Base 8 would decr…

That's not a pure number system though, because it didn't have a separate character for each digit

Re: The case against a C alternative

#314

Post by xorvoid »

The article misses a really big item.

I’ve programmed in C for 20+ years and then recently switched to rust. When fellow C programmers ask me how Rust is going, I say “it’s modern” and “it’s consistent”. What I mean by that unlike C, Rust doesn’t have 50 years of baggage: string functions that handle null termination all differently, complicated implicit promotion rules, null-terminated strings that haven’t been a good idea for decades, apis that we’re completely busted by posix threads but still exist, functions that cannot be used safely that still exist, code snippet examples with horribly broken unsafe code that beginners copy-paste, dubious and bad type-based aliasing, rampant use of UB, etc etc etc

Sadly Rust is not a better C. Maybe it’ll grow into one some day. Today it’s a better C++. Sadly I’d still chose C to do C’s job.

All I want from “better C” is to fix the obviously bad problems from C’s history. Or rather, maybe that’s the committee’s job.

At any rate: it’s embarrassing that we’re still so dependent on a language that’s so broken. And it’s sad that there doesn’t seem to be a path forward.

Re: The case against a C alternative

#315

Post by alpaca128 »

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 also like this priority in Rust, which constantly makes me wonder why the developers allowed shadowing. It has already caused runtime bugs for me while the compiler didn't even throw a warning about it, and as Rust is otherwise so strict about making possible mistakes like this explicit it's definitely not the first cause I consider when debugging.

Re: The case against a C alternative

#316

Post by afiori »

account42 wrote: post #312
afiori wrote: post #265

Earlier quoted context omitted.

The EU can fine US companies the same as it can fine most other extraterritorial companies, that is only if the other country allows it. The EU is not going to start an armed invasion over a GDPR violation. Still big multinational companies will have international branches (Google, Amazon, Microsoft, ...) that can easily be fined in their host countries.

The EU can also prevent companies from doing business in the EU if they don't follow the local laws. No need for an armed invasion if the EU can block all transfers from EU banks for anything related to your company.

I think GP was referring to enforcing GDPR against companies that do not do business in the EU (no employment, no sales, no bank account, no revenue, no taxes, etc.).

For example, a company like Digital Ocean might have no assets of any kind in the EU (assuming that they don't own their European datacenters), so the EU cannot force them to pay a fine nor seize their assets; the EU could technically sanction them by stopping EU datacenter providers (like AWS-Germany) from renting compute to Digital Ocean, but maybe not for something like a GDPR violation.

Re: The case against a C alternative

#317

Post by david2ndaccount »

flohofwoe wrote: post #163
david2ndaccount wrote: post #114

Earlier quoted context omitted.

zig cc has enough bugs in it that I just went back to using clang on each platform.

What you're seeing is most likely not bugs (it is clang after all), but the result of the much stricter default compilation settings in "zig cc" which tends to break a lot of C code that hasn't been checked against a static analyzer or ASAN before.

No, they were bugs in zig CC. They were things like linking against the wrong frameworks on macOS.

Re: The case against a C alternative

#318

Post by alpaca128 »

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…

> allocate a buffer at startup and let the system clean it up when the program exits

This is possible with the lazy_static library or (not yet in stable Rust) OnceCell. It allows you to allocate & initialize any datastructure once during runtime and get global read-only access.

Re: The case against a C alternative

#319

Post by proto_lambda »

alpaca128 wrote: post #315
Ygg2 wrote: post #302

Earlier quoted context omitted.

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 also like this priority in Rust, which constantly makes me wonder why the developers allowed shadowing. It has already caused runtime bugs for me while the compiler didn't even throw a warning about it, and as Rust is otherwise so strict about making possible mistakes like this explicit it's definitely not the first cause I consider when debugging.

While I think shadowing is great for code readability and I've never encountered a bug caused by it, you can always make sure clippy doesn't let you do it by putting a `#![deny(clippy::shadow_reuse, clippy::shadow_same, clippy::shadow_unrelated)]` at the top level of your crate.

Re: The case against a C alternative

#320

Post by jstimpfle »

bluGill wrote: post #293
jstimpfle wrote: post #267

Earlier quoted context omitted.

> It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language. On the other hand, empirically, it is not unusual to see straightforward C programs being dramatically faster than comparable C++ programs written in enterprise style, and to also build much faster. > Last but not least, you would have to be a masochist to write heavily multi-thread…

> On the other hand, empirically, it is not unusual to see straightforward C programs being dramatically faster than comparable C++ programs written in enterprise style, and to also build much faster. Your only comparison cases are cases where the code in question was re-written in C. This most likely means that everyone already knew it was slow and so the re-write also fixed the fundamental problems. If the code had…

> it is known that if you switch from gcc to g++ your code often will run faster if it compiles)

I've never heard such a claim, can you back it up? And what does it say about the language?

> and it is a lot more maintainable

If you equate "maintainable" = readable, I've never once seen maintainable enterprise code. Everything is a convoluted mess that never gets anything done. Probably I haven't worked at the best shops, but then again, where are those? And why doesn't the language help mediocre programmers to write maintainable code?

I suspect that maintainability is almost exclusively a function of experience, not the programming language used. Experienced programmers do seem to agree that C-style C++ or even plain C is the way to go.

Post reply on HN