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

221–230 of 388 posts

Re: The case against a C alternative

#221

Post by msla »

mwcampbell wrote: post #211
jcelerier wrote: post #208

Earlier quoted context omitted.

> I don’t know dude, if you want to write software for the worst performers instead of commodity hardware that’s up to you I want to write software that people, most people, not only those with SV salaries able to buy a computer every year, can use. Here's the current best seller laptop in Amazon in my country: https://www.amazon.fr/Dell-Inspiron-i5-1135G7-Ordinateur-por... It's half past 2022 and the most sold lapto…

Thank you! Please keep pushing such certifications until they become regulations that, like GDPR, even we American developers cannot ignore. Then I can make a strong business case to move away from Electron in the product I'm currently working on. Edit to add: Related to your links to best-selling computers, I've been thinking about downgrading to a low-spec PC as my daily driver, and using a remote machine for the t…

> 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 offer goods or services to EU residents[1]. While the GDPR requires these companies[2] to follow its data processing rules, it leaves the question of enforcement unanswered. Regulations that cannot be enforced do little to protect the personal data of EU citizens.

> This article discusses how U.S. law affects the enforcement of Article 3(2). In reality, enforcing the GDPR on U.S. companies may be almost impossible. First, the U.S. prohibits enforcing of foreign-country fines. Thus, the EU enforcement power of fines for noncompliance is negligible. Second, enforcing the GDPR through the designated representative can be easily circumvented. Finally, a private lawsuit brought by in the EU may be impossible to enforce under U.S. law.

[snip]

> Currently, there is a hole in the GDPR wall that protects European Union personal data. Even with extraterritorial jurisdiction over U.S. companies with only an internet presence in the EU, the GDPR gives little in the way of tools to enforce it. Fines from supervisory authorities would be stopped by the prohibition on enforcing foreign fines. The company can evade enforcement through a representative simply by not designating one. Finally, private actions may be stalled on issues of personal jurisdiction. If a U.S. company completely disregards the GDPR while targeting customers in the EU, it can use the personal data of EU citizens without much fear of the consequences. While the extraterritorial jurisdiction created by Article 3(2) may have seemed like a good way to solve the problem of foreign companies who do not have a physical presence in the EU, it turns out to be practically useless.

"Patching" that hole seems to require either action on the American side or, perhaps, a return to old-fashioned impressment or similar projection of Majestic European Power to Benighted Lands Beyond the Ocean Sea. /s

Re: The case against a C alternative

#222

Post by rahen »

aerxes wrote: post #195
jcelerier wrote: post #186

Earlier quoted context omitted.

Gaming is very much not representative. There's roughly 120M active steam users, vs. ~1.4 billion windows installs. If I look around me, for instance in my whole family we're two with Steam installed but ever household has a desktop or a laptop (and generally a 7-8 years old cheap entry-level 350€ one, you'd be hard-pressed to find even a quad-core in there)

I don’t know dude, if you want to write software for the worst performers instead of commodity hardware that’s up to you Just that single core systems are dying and probably won’t come back. Even Raspberry Pi’s are quad core now.

Writing for the top performers is the main reason why computers turn into e-waste. It's Wirth law applied.

I wish more developers would work on RPIs for the same reason.

Re: The case against a C alternative

#223

Post by substation13 »

AceJohnny2 wrote: post #35
AceJohnny2 wrote: post #30

> 3. Programmer productivity > [...] Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register. This reminds me of Amdahl's Law [1], about how a performance optimization (parallelism) has small returns because the performance improvement only affects a small po…

Counterpoint is that a language that allows rapid iteration/prototyping (and thus, increases "programmer productivity") is useful precisely because it helps figuring out what the task really is.

100%.

This annoys me so much in Java debates. The argument goes something like "It doesn't matter that Java is verbose and requires hundreds of files because the IDE generates them for you". And this is true... when you write the code. But the real friction is when you must read or change the code in response to new requirements, which is exactly what we as engineers spend the bulk of our time doing.

Re: The case against a C alternative

#225

Post by jstimpfle »

mort96 wrote: post #171
GuB-42 wrote: post #125

Earlier quoted context omitted.

I don't know Rust but I know C++. And C++ has the potential to be faster than C, mostly thanks to metaprogramming (templates, ...). It is horrible if you have to do it, but if you are just using the standard library, you don't have to feel the pain but still take advantage of it. That's how algorithms are implemented. Because so much is known at compile time, optimizers can do a lot. The reason C++ is generally regar…

> Modern C++ also discourages raw pointers and so you get references counters all over the place, essentially turning C++ into a garbage collected language. This doesn't match my experience. It's true that modern C++ discourages owning raw pointers, but the solution is usually unique_ptr, not shared_ptr. Truly shared ownership is actually pretty uncommon IME, usually you can have one entity which obviously "owns" the…

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.

Re: The case against a C alternative

#226

Post by Gibbon1 »

markdestouches wrote: post #214
ryandrake wrote: post #54

Earlier quoted context omitted.

> I would much rather have my computer run slower than have to continuously deal with security vulnerabilities. My time is much more valuable than CPU time. To be devil’s advocate and take the other side of this argument: I would rather the CPU I paid for spend its cycles performing actual application logic. Every cycle spent executing all this “safety code” overhead feels like me having to pay for a developer’s slop…

The real overhead is not safety code but inefficient design and unnecessary (and often detrimental to the user) features. The added 10% of safety checks is nothing compared to orders of magnitude of bloat modern software has. Moreover, a lot of C codebases have the same safety checks manually implemented into them, sacrificing performance in order to have less bugs. And when it comes to designing a modern C alternati…

I'm suspicious that people arguing that safety checks making things slow are basing that on the very stale now idea that CPU's work sequentially. Which isn't true for super scalar machines at all. And also forgetting compilers will optimize away a lot of them.

There is an asymmetrical risk here. On one hand the compile might emit checks that aren't needed. On the other that the programmer will fail to insert a check that is needed.

Re: The case against a C alternative

#227

Post by JonChesterfield »

flohofwoe wrote: post #161
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…

> become dramatically faster when rewritten in a more modern language IME that's mostly a myth though. A C compiler will stamp out a specialized version just as well if it can see all the relevant function bodies (either via inlining or LTO). "Zero cost abstraction" isn't just a C++ thing, it happens mostly in the language agnostic optimizer passes. For instance the reason why std::sort() shows up faster in benchmark…

It could and it should, but function specialisation without inlining is still on the wish list for llvm last I checked.

Re: The case against a C alternative

#228

Post by dagw »

jiggawatts wrote: post #60
woodruffw wrote: post #40

> Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. I don't think this is true, in the general case: Rust has shown that languages…

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…

It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language.

This was equally true back when C vs Fortran was the big debate, and something not easily captured in benchmarks. C, as written by an expert in high performance C, was equally fast as Fortran written by an expert in high performance Fortran. C, as written by a domain expert with limited programming skills, was often very much slower than Fortran written by a domain expert with limited programming skills.

Re: The case against a C alternative

#229

Post by badpun »

Honestly, I hate includes and preprocessor directives so much that any "better C" variant which replaces them with more modern solutions would probably be enough in my book - with the caveat being that I also like having an IDE very much and wouldn't want to revert to coding in something like emacs with plugins. BTW, C++20 has a good replacement for includes (modules), but IDE support is not there yet and thus it's not usable for me.

Re: The case against a C alternative

#230

Post by enqk »

jimbob45 wrote: post #131
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…

What did you mean when you said C hashtables can’t be generic? Is the (void*) not an adequate solution?

Another perfectly good solution is to treat a C hashtable as a sort of acceleration index. That C hashtable then, rather than holding pointers simply holds `hashkey -> i` where i is the position into a typed array.

I.e. your data structure is like this:

  generic_hashtable Hash; // (hash->int)
  Foo *values; // where my typed data is.
Post reply on HN