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

The Problem with C (2020)

cor3ntin.github.io

Post reply on HN
Print view View original

101–110 of 177 posts

Re: The Problem with C (2020)

#101

Post by marwis »

pjmlp wrote: post #79
badsectoracula wrote: post #77

Earlier quoted context omitted.

D-Bus is for IPC not an ABI. If there was something similar it'd be gobject, but i don't think any language other than Vala speaks it "natively" (and considering how much Gtk cares about backwards binary compatibility, i don't think it'd be a good idea to target it anyway).

It can run in-proc and fits the scenarios being given on previous comment. I remeber Bonobo, DCOP and KPart days, so I know pretty well what D-Bus is capable of. In micro-kernels the IPC infrastructure is the userspace ABI, as it is the only way to call into OS services, beyond the little glue library to make it possible to do so.

Where did you see in-proc D-Bus? It would be wildly inefficient compared to COM/gobject anyway.

Re: The Problem with C (2020)

#102

Post by sirwhinesalot »

flohofwoe wrote: post #94
sirwhinesalot wrote: post #68

Earlier quoted context omitted.

Your comment is assuming that language A knows about language B. That's one case, but not the usual one. Rather, languages like Rust/Zig/C++ and even C# and Java let you expose a C API such that other languages can understand the shared library as if it was written originally in C, because C is the only thing every other language talks. By necessity this involves using standard types available in C otherwise the othe…

> If C had better builtin constructs... Such annotations exist in specific compilers (e.g. clang has things like _Nullable and _Nonnull), they are just not part of the standard (unfortunately). But those annotations are visible in Clang's ast-dump, so they can be used to create more correct language bindings.

Yes, I'd love it if they got standardized. Having them implemented in a C compiler already helps quite a bit for more "standardized" adoption over some ad-hoc approach.

I certainly don't want C to be getting exceptions or templates or other heavyweight constructs, just some QOL stuff that allows for more semantic information to be shared.

Re: The Problem with C (2020)

#103

Post by sirwhinesalot »

seiferteric wrote: post #99
smorgusofborg wrote: post #76

Earlier quoted context omitted.

> Your comment is assuming that language A knows about language B. That's one case, but not the usual one. You are free to expose an API where strings are not null terminated, etc. Anyone in any language is going to have to work their data into the API you provide so if it is alternatively complicated to make an intermediary language happy that's not really helping.

This brings up a vague idea I have had. Redis is sort of a data structure server that can be used across languages. Could we not have an opensource data structure and algorithm library? Where languages, instead of implementing their core types and algorithms in their own library, instead add them (or reuse existing) ones to this library. Then your language becomes just a mapping of your languages semantics over these…

Unfortunately this doesn't work for managed or interpreted languages with their own runtimes, where you want the types to run on their VM.

An example would be JIT-compiled C# data structures, no way to implement those on top of a shared library since specific instantiations have to be produced and compiled at runtime.

Such a data structure and algorithm library as a springboard would be still be incredibly useful, but then you wonder why it's not called "the C standard library" :)

Re: The Problem with C (2020)

#104

Post by pornel »

_the_inflator wrote: post #40
sirwhinesalot wrote: post #31

Earlier quoted context omitted.

> C is the glue interface that connects all the different languages together. I wouldn't want to see anything new added to the language that complicates this lingua franca. Indeed, this is one of the two things where C is still king, the other being running on weird hardware with specialized compilers. That said, C is not a great glue language: - Zero terminated strings are only used in C so every other language need…

I agree with you. However, I think the real value of the language is that, despite flaws, it provides a reasonably consistent platform in this "glue" context. It better to have one imperfect language, than a dozen perfect.

I think it would be beneficial to create a better interoperable ABI description (one, not a dozen). Not in a form of a language header, but a data file that can be easily consumed by tools of any non-C language.

1. C headers are exceptionally annoying to correctly parse and interpret. You basically have to have a full C compiler, which is a PITA for a non-C tool. It's not just complexity of the C syntax, but dependency on system headers, implicit platform-specific type sizes and struct layouts, and an arbitrary web of ifdefs which may need to be generated by an arbitrary build system. Everything here resists automation, and if you get any details wrong, you won't know until you see memory corruption.

2. The common baseline between most programming languages has outgrown what C can express. Namespaces and other name mangling, unwinding, non-nullable types, slices, ownership/destructors, thread-safety annotations, etc. C++ has some of these features, but it solves none of the above problems, and only adds more complexity and its own compiler-specific behaviors.

Re: The Problem with C (2020)

#105

Post by jon_north »

If I'm writing C++, I am doing it because I need nanosecond latency (and the delicious language libraries). If I only need microsecond latency, I would use Golang. If millisecond is fine, it'd be Python in a hot minute.

If I only need (as is 99% of the time the case) a smidge of code to run nanosecond-fast, I'd write a C extension and call it from a higher-level language that does the orchestration code. The C extension would by definition be simple code, so there is no real problem with C as such - it's ideally suited for that role.

Only in the rare case that a large program needs to be nanosecond-fast would I even consider C++ (and I'd push really hard to learn if that really needed to be true!), and then I'd write code like it was 2003 - smart pointers and POD classes, but that's it. The new libraries are wonderful for saving code and getting good fast implementation of algos!

Re: The Problem with C (2020)

#106

Post by seiferteric »

sirwhinesalot wrote: post #103
seiferteric wrote: post #99

Earlier quoted context omitted.

This brings up a vague idea I have had. Redis is sort of a data structure server that can be used across languages. Could we not have an opensource data structure and algorithm library? Where languages, instead of implementing their core types and algorithms in their own library, instead add them (or reuse existing) ones to this library. Then your language becomes just a mapping of your languages semantics over these…

Unfortunately this doesn't work for managed or interpreted languages with their own runtimes, where you want the types to run on their VM. An example would be JIT-compiled C# data structures, no way to implement those on top of a shared library since specific instantiations have to be produced and compiled at runtime. Such a data structure and algorithm library as a springboard would be still be incredibly useful, bu…

I wonder though, I know a lot of tricks for performance are used, such as in python API, judicious use of inlining, putting some common functions in headers files etc. Depending on how far down the rabbit hole you want to go, could this library not also include code generation functionality for JIT's? Or even at compile time, is there anything stopping a library from generating code that could be included in your VM runtime as just an opaque function that can be called?

Re: The Problem with C (2020)

#107

Post by gk1256 »

C is a terrible language. You have to reinvent everything on it. The simplicity is just a lie.

C++ on the otherhand is way simple to use and really straightforward.

I like Zig too.

Re: The Problem with C (2020)

#108

Post by bitwize »

loup-vaillant wrote: post #65
google234123 wrote: post #29

Earlier quoted context omitted.

Your examples for why C++ is bad are references, classes, and templates? So I guess you like Fortran77?

References are kind of redundant when you already have pointers, and they make the performance characteristic of the code you read less clear (am I passing down a pointer, or am I copying the whole thing?). C structs can already do most of what C++ classes can do. Including inheritance and virtual methods, when you really really need them. As for encapsulation, pointer to implementation provide a more stable, harder…

> References are kind of redundant when you already have pointers,

No. They're not. References must point to valid objects (i.e., cannot be nullptr and cannot be random addresses in memory), and you cannot do arithmetic on them. They are much safer to use than pointers, so actually, references make pointers redundant.

> C structs can already do most of what C++ classes can do. Including inheritance and virtual methods, when you really really need them.

Only much more cumbersomely.

Re: The Problem with C (2020)

#109

Post by sirwhinesalot »

pornel wrote: post #104
_the_inflator wrote: post #40

Earlier quoted context omitted.

I agree with you. However, I think the real value of the language is that, despite flaws, it provides a reasonably consistent platform in this "glue" context. It better to have one imperfect language, than a dozen perfect.

I think it would be beneficial to create a better interoperable ABI description (one, not a dozen). Not in a form of a language header, but a data file that can be easily consumed by tools of any non-C language. 1. C headers are exceptionally annoying to correctly parse and interpret. You basically have to have a full C compiler, which is a PITA for a non-C tool. It's not just complexity of the C syntax, but dependen…

It has been attempted at least at the OS level. COM and the much improved WinRT are one example (WinRT relies heavily on metadata), the Objective-C runtime on Apple platforms is another (which instead accepts lots of dynamism).

The problem is that OS vendors are the only ones with enough sway to force people to use these things, and even then just barely (the Rust WinRT support is developed by Microsoft themselves).

The only entity with enough sway over every language in existence when it comes to supporting an ABI is, ironically, the C standards committee, because every language already talks C and needs to continue to do so.

Re: The Problem with C (2020)

#110

Post by gk1256 »

cortexio wrote: post #54

For me, C is perfect and just works and C++ doesnt. That being said, both their std libs are a big mess. It's absolutely horrible. The problem is the macro preprocessor. It's a horrible feature that should not have existed.

C is not perfect. It's closer to assembly, but you can't do anything useful without reinventing most things that is already done in C++.

C++ STD lib is not a big mess. At least, I am using it for decades. I don't know if you really used it because those who are against STD doesn't understand the point of abstractions and it's utility. They always tend to cite why would I use vector when I can create a "simple" linked list myself with pointers.

Post reply on HN