Hacker News Reader

That’s a good reason to create a new language. But all the C code in the world isn’t suddenly going to go away, and so the need for an improved C still remains.

That’s why LLVM is such a great idea - any llvm language can interoperate with any other, within the same binary, with no overhead. Apple isn’t throwing away their C code any time soon either. LLVM provides a smooth upgrade path via mixed language binaries.

I suspect that the move to swift would never have happened without LLVM. And I wouldn’t be surprised if llvm’s cross language compatibility was specifically attractive to Apple because it let them have their cake and eat it too - write a new language but keep legacy C code whenever that’s the best option.

It is a great idea, but not an innovative one, already PL/8 for IBM RISC research used a similar approach.

> That’s why LLVM is such a great idea - any llvm language can interoperate with any other, within the same binary, with no overhead.

I don't believe LLVM provides a stable cross language ABI, and AFAIK languages just use regular FFI (via the C ABI) to communicate with one another, regardless of them being implemented on LLVM or not.

> I don't believe LLVM provides a stable cross language ABI, and AFAIK languages just use regular FFI (via the C ABI) to communicate with one another

Provided the compilers generate compatible versions of LLVM IR, then cross-language calls can be done at the IR level. See github.com/Keno/Cxx.jl

IIUC Swift already uses clang to load module maps in order to expose and call Objective-C, and they plan to do something similar with C++ (no link handy but I think there is an issue or enhancement proposal about it).

Yeah, Swift’s C interop goes further than most typical FFIs because it actually calls into Clang internals to read headers, lay out structs and form calls. C and Objective-C types, functions and methods are mapped to Swift definitions, by directly looking at the Clang AST.

> C ABI

Is there really such a thing? I thought the ABI was dependent on the operating system and compiler.

I agree that C is unique in it's ability to generate programs that can be interfaced with from any language. This also seems to apply to older languages like Fortran and Pascal, for some reason. Higher level languages are an ABI nightmare; seriously doubt anyone will ever dynamically link against a C++ library at runtime and call a method on a C++ object from any language that isn't C++.

1. As someone says, LLVM does not have a cross-language ABI, so no, it's not as easy as you think. It makes some things nicer, some things harder.

2. Prior to LLVM, there were much more complete attempts at this (that were even more successful, actually!)

As the siblings have mentioned, llvm doesn't really do this. What does, though, are the jvm and .net, although those aren't really oriented towards low-level c programming.

Language design graveyard is full of improved C attempts, because the problem is not technical, rather it can only be properly solved through change of generations.

Microsoft, Apple, Google have the luxury to impose moving away from C on their platforms.

On other platforms you have developers that won't touch any kind of Safe C even at gun point.

My guess is that a lot of the C hold-outs will never switch to another language. C represents the siren's call for them: the best performance, requires skilled handling, no seatbelts, stable definition.

A lot of C's endurance is related to programmer psychology, so it would be futile to design a better C.

C++, Rust, Go, Java will continue to drain the pool of C developers until it's only used for maintenance of existing projects.

This is why it's extremely irksome to see people recommend mixing C and e.g. Python for speed, or other such Frankenstein's monsters - it's just prolonging the agony of whoever will maintain that.

C still represents the closest approximation of what is happening on a chip, quasi-atomic operations acting on finite resources like registers, memory, and I/O. Even if you don't know assembly, you can reasonably understand what various chips will do with your C code, especially low level C code that occasionally dips into assembly (e.g., handling interrupts or chip-level atomic operations).

Rust, Go, and Java, with their memory management and cross-platform portability, and general non-determinism may eat away at the edge of C, but can never replace it.

I could see them fully replacing C if features like garbage collection and byte-code interpretation were handled at the chip-level, so languages would not have to necessarily deal with them. Could also see it happening if a chip's out-of-order execution was exposed at the language level. That would not necessarily make C worse, but Java may be more adept at handling it.

You've made several points...

1. C is no closer than C++, or Rust (including unsafe) and they're all surprisingly pretty far from the hardware these days... this is visible the most in multi-threading, where high-level C statements are re-ordered by the compiler and even simple C statements like an integer assignment can be split into multiple instructions. Inlining and register allocation is also quite opaque and perhaps best left to the compiler, unless one uses non-standard code to force specific behaviour.

2. Well put: Go and Java were/are eating at the edge of C. Java took serious bites in the past, nowadays they're not really competing much. Today, what might have been a small Linux C program could be a Go program, especially if the performance constraints aren't too tight. Technically speaking, Rust can replace C almost everywhere, it's just that it's a significantly more complex language.

Regarding 2.

I am fully convinced that if Java and .NET had a proper AOT toolchain from day 1, meaning beyond dynamic linking (NGEN) or commercial offerings from 3rd party JDKs, C's influence on FOSS world would have been much less than it achieved to be.

And we would already have achieved an UNIX like stack closer to what Inferno/Limbo was all about.

Regarding #1, disagree. In C, a function call is just a request to send the instruction pointer to another point in the memory space. In C, code is treated as data, which is how it's treated in hardware.

C++ introduces virtual functions, and when you make a function call, you're no longer going to a single place in memory, you go to where the class's virtual function table tells you to go, effectively jumping to a memory pointer. This is pretty helpful, but it's an incredibly different way to think about code. A function is no longer a set of instructions in memory, it's a logical representation of functionality.

And yes, I know in C, you can set a variable to a function location, and then jump there, but it's painful to do and you have to do it explicitly, so it doesn't really create an abstraction.

> you couldn’t use C arrays on the stack, for example. And if you couldn’t do that, there’s entire classes of applications where the performance just wouldn’t be acceptable

Would you mind naming a few such classes?

Why would arena allocation, or evrn good generational GC fail to deliver the performance when quick allocation / deallocation of (large) arrays is required?

Generally one feature GCd languages lack is strong support for value types. Cache thrashing due to pointer chasing is an issue, and even if you can allocate large numbers of small objects quickly, the indirection will kill you. In Swift, many small allocations are avoided entirely by storing the value as part of some other object. For example, imagine you want to store an array of points; it’s usually much better if you can have an array of structs of floats where everything is represented as one flat allocation.

C# had value types from day one.

And ....

Yeah, its one of the few that does. Even then, C# value types are immutable, and there are no value type collections (not a collection of value types, but a collection that is itself a value type). The lack of these two features means it’s not as generally useful as you might like.

An array of value types (including structs) in .NET (not just C#) is laid out contiguously in memory and stored in-place like an array of C/C++ structs would be. The problem of chasing pointers does not exist if you use structs (and don't use non-value types such as strings within those structs). And .NET value types are mutable, of course.

Right, but the array itself has reference semantics.

Not when you allocate it on the stack via stackalloc, as of C# 7 also allowed in safe code.

Oberon, Oberon-2, Active Oberon, Component Pascal, Eiffel, Common Lisp, Modula-2+, Modula-3, CLU, C#, D all have strong support for value types.

Java just made a couple of wrong decisions regarding AOT and value types that are now taking years to correct course, while avoid breaking backwards compatibility.

If something like Modula-3 had been granted Java's success story, we wouldn't be talking about how GC languages don't have good support for value types.

I think we have different definitions of value types - in all Common Lisp implementations I’m aware of values have a uniform representation as a (tagged) pointer.

Also I think C# structs do not have mutable fields, but I could be wrong.

Edit: it looks like C# structs are mutable, my mistake.

Common Lisp is just one example among 11 programming languages that I have listed.

Maybe take some time to check the other ones?

As for value types in Common Lisp, even if one bit is lost for tagging, it doesn't make arrays, structs and primitive values, less of value types.

ARC in objective-c has almost fully solved this issue in practice.

Try to use ARC with C APIs.

That's like saying try to use Java JNI with C APIs. Think of direct C API access in Objective-C a bonus, not a design pattern :)

Completly different, ARC only works with APIs that follow Cocoa retain/release patterns, which aren't the only APIs that one needs to use, e.g. CoreGraphics.

And unlike JNI they aren't protected by a VM wall.

Nope. I still found many ways to crash my objective C apps while using ARC. Because Swift is memory safe I no longer have to give up days or weeks of my life tracking down obscure bugs caused by overwriting memory I should not have.

Thanks for having the patience to put all these Obj-C myths to rest.

The Obj-C community (or what's left of it) is trying to make a martyr of an error-prone, cumbersome programming language.

Could you please give some concrete examples of how memory corruption has affected you in modern Objective-C? NSArray has range checks, delegates can't dangle anymore because they're weak references now. I think that leaves interaction with C APIs, but don't Swift users have to deal with UnsafeMutablePointer to use them - which isn't memory safe either?

The easiest way to cause memory issues is to access mutable collections from multiple threads. I really wish NSMutableArray and friends were thread safe...

Unfortunately, Swift doesn't fix that AFAIK.

No no no. That is a one-way trip to hell. There is no ”good for all threading scenarios” thread safe mutable array design.

I’ve debugged too much java code where the programmers thought that ”thread-safe” meant ”no need to think about threading issues”.

I can understand the need to create a new programming langauge, but as the previous poster wrote, they rather recreated all the complexity of C++, instead of a more lean language. Also, Swift seems to suffer from overly static typing in its object oriented approach - which defeats the idea of object oriented programming.

> they rather recreated all the complexity of C++

I find that this assertion holds about as much water for Swift as it does for Rust, Swift is not even remotely close to C++'s in terms of complexity, and that's with building in mechanisms for performant memory safety, a concept which C++ literally just shits on to this day and for the foreseeable future.

Swift is complex, but it is not C++-complex. C++ is in the completely different league.

It’s hard to take seriously the idea that swift and c++ have equivalent complexity if you have delivered products using both languages.

It’s not even close. Swift is (still) minimalist by comparison to C++.

Swift is a really approachable language, it’s core features are simple and the code is very readable. You can write any app without having to use generics, extensions, protocols, more esoteric enum features, etc, etc.

But once you learn to use the more advanced features, your code just gets easier to write and maintain. I enjoy that I can pickup new language features in Swift one at a time, figuring out where each adds its best value, and occasionally refactoring to take advantage as part of my ongoing efforts to minimize code debt.

That's extremely hyperbolic. I've worked on multiple C++ FEs and it's orders of magnitude more complex than Swift.

As an embedded engineer I can’t agree that C “has problems” because it treats you like a big boy with your big boy pants on. :)

Which is a problem for developers who simply want to write code without having to reason about whether it’s safe to dereference something, and without having to worry about a simple oversight resulting in the programmatic equivalent of summoning Cthulhu.

>a problem for developers who simply want to write code without having to reason

Still not seeing the problem.

Pointers aren’t magic and aren’t hard.

Oh boy, trying to debug some miscompile because of a subtlety in aliasing rules would make me disagree.

Pointers, conceptually speaking, are not hard.

Pointers, in practice, are hard. Even C-family compilers cannot safely reason about them in many (most) cases.

I work almost exclusively in embedded C and even I can’t agree with this. Just for starters, those two statements are not mutually exclusive.

As a C compiler engineer I can assure you it has problems.

Did I say C didn’t have problems? Or did a say it’s not a problem that C might allow you to do unsafe things?

I think so?

“As an embedded engineer I can’t agree that C “has problems” because it treats you like a big boy with your big boy pants on. :)”

Do you know what “because” in that sentence means?

Edit: Nah, that’s OK. Just downvote and scamper on. Make HN more like Reddit, that’s what this place needs!

Could you please stop posting unsubstantive comments to Hacker News?

Well I took it to mean that because you think it treats you as a "big boy" you don't think it has problems.

Oh and I have no idea how to downvote on HN. Not that I care, but I don't see any downvote buttons.

There is no such thing as "big boys" in software engineering, there's only humans which have certain cognitive weaknesses.

C is really good at exploiting those, while at the same time giving programmers a feeling of power.

So providing a feeling of power over the language and it's abilities is not a legitimate advantage of the language?

Isn't that why everyone loves python, solving a complex problem in a handful of easily readable lines of code?

The feeling of power is nice for the programmer, but it doesn't influence the technical capabilities of the language, which are deplorable safety-wise.

Did you see the smiley face in my post that’s implied I’m kinda joking.

Also... I’m a little concerned that your post has “we’re all equal” social justice vibe to it... which is silly. C is more powerful than because “safety features” aren’t there.... deplorable... LOL.

You try going a day without using something programmed in C.

Every single day back when I was developing software for ZX Spectrum, Amiga and MS-DOS, before UNIX's influence took over the industry and forced us into dealing with C.

Thankfully there was already C++ for those of us that wouldn't move into such a limited language versus what something like Turbo Pascal 6.0 for MS-DOS was already capable of, feature wise.

Ok... so if I’m getting the idea here... C is more limited, but also dangerous because it gives direct access to memory and pointers making it dangerous.

Man... to listen to hackernews tell it... no one should use C!

I wonder how many comments describing how bad C is are from people on Linux machines?

The problem is not direct access to memory and pointers as such, every systems programming language needs to provide such features.

The problem with C, versus other systems programming languages it that it its pointers, implicit conversions of array into pointers, integer operations, string and array bounds don't have any kind of validation.

On other systems languages disabling such validations is explicit.

C is like JavaScript in the browser, we have to put up with it because UNIX clones won the market of commodity OSes.

C on its own without UNIX, would have failed in the market.

On the desktop world it was already being replaced by C++, Smalltalk, VB, Delphi and 4GL before FOSS based on UNIX and C started to be widespread.

Unfortunately it is impossible to convince people on pure UNIX based OSes to use something else.

Fortunately, Apple, Microsoft, Google, Sony, Nintendo are able to set which programming languages one is allowed to use on their platforms and C is on the way out on their SDKs.

LOL yea, C is going away alright. Just as soon as every company you mentioned and everyone else in the world stops making embedded electronics!

Tone is a tough thing to get right, and I'd say your initial post came off pretty condescending to a lot of people, regardless of whether you meant it or not. It's not even a C thing either, I've seen the same thing where someone declares functional programming as the only "serious programming" and category theory is easy, so everyone else is wasting time with imperative languages. So, it's a bit off-putting.

Oh boy, how I wish I could have at least one day without something programmed in C. I'm so sick of all the vulnerabilities...

No social justice vibe was meant. I was trying to say that we're all bad at dealing with the kind of errors which appear in a typical C or (perhaps to a lesser extent) C++ program.

I know that some people are able to do this more successfully than others because of skill, etc, but it's not just about certain individuals. As a whole, the C community has a really poor track record at security and safety and that has a lot to do with the language itself.