Isn't it the fate of all programming languages? they start on clean foundation, only to evolve in a bazaar of features.
You can call it a moot point since the amount of what you can do in pure C today is very limited - you have to use at least a few libraries to do anything remotely useful even on very light systems, but in today's fast developing tech world it's one of these things that really stand out.
You might find this an interesting perspective:
There's just so much prior art out there.
Having a core language helps a lot too. E.g. I don't expect Rust to go off the rails.
For instance sync rust is mostly nice to work with, but async is another story entirely. I have the impression that it was somewhat rushed into the language due to community demand, but it's not really a fully solved problem.
My understanding is this is a FUD meme that has been passed around. Async isn't finished yet, but was debated for years and considered with incredible care and input from the community.
more context in the comments here: https://news.ycombinator.com/item?id=26406989
specifically https://news.ycombinator.com/item?id=26407565
Surely you want to use the pure rust async aware postgres client and the pure rust grpc implementation, but with async that's not a free choice.
You now have to deal with the fact that these (actually often quite well written) reimplementations often lag quite a bit in functionality.
For example you think you can just use some boring technology like a RDBMS but then you discover that pgbouncer doesn't really work well with sqlx. Similar stories for gRPC and other stuff.
Don't get me wrong, I'm not saying that's because async implementation is bad or it hasn't been well thought out. Other languages make other tradeoffs (e.g. Go detects blocking syscalls and increases the size of the thread pool, which makes it a bit easier to accomodate blocking FFI with the core async model, but that comes with a price).
What I'm saying is that in practice async rust feels like another language, a language built on top of rust, that looks like rust, that can call rust, but effectively creates its own ecosystem. The problem is compounded by the fact that it's still called rust, and often you can write libraries that can do a bit of async or not based on optional features.
It's probably all unavoidable and for the better, but it does add a source of fatigue that must be acknowledged and not dismissed as FUD.
I'm not sure what the GP meant, to be honest. Async "colored" code does have an tendency to "infect" more and more of your codebase, but you can still write and integrate big chunks of non-async code (e.g. a parser or a network protocol) if you're mindful about your design.
I could be wrong though. The reason I like to discuss these things here is the opportunity to be proven wrong by someone who knows more and offers a counter-example
https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.ht...
But you need to know when you must call this and when it's ok to not call it.
The type system won't help you with that. But if you forget to call it you can cause starvation and if you call it too often you may create too many threads.
What I see in the ecosystem is that such tricks are perceived as hacks and that it would be just better if one could just write a pure rust reimpl.
Surely there are enough reasons that drive people to reimplements stuff in rust. I think this aspect of async nudges people even further into that though.
In return, of course, you get a style of concurrency that tends to be much easier to reason about and much less prone to subtle bugs than traditional preemptive multitasking.
Whether that tradeoff is worth it is obviously very dependent on the particular situation.
Still, the fact that Rust has MIR I think very much limits the damage premature async can do. If we get something better, it should be quite possible to extra "Rust - today's async" to recreate it.
Conversely, I wouldn't be surprised if many of the misfeatures in Switch are in impossible to extricate.
[^1]: https://blog.rust-lang.org/inside-rust/2022/02/03/async-in-2...
Unless the rails are too rusty :-)
You would have 2 lines of code per property but one fewer concept—and I think that is a much more important factor. To me—this was not the right way to add sugar.
When I started, I thought it would be some complicated beast, but no - its a reasonably simple and elegant C superset with the only disadvantage of some extra verbosity. (but Apple API's suffer from verbosity as a principle)
I have to wonder: why did Apple create Swift ? Objective-C is quite nice, especially for C/C++ programmers. With Objective-C++, interop with C++ libraries is also terrific. Swift offers nothing like this yet.
They wanted a safe, performant language that interoperates with Objective-C. Safety gets them fewer vulnerabilities, interoperability means they can gradually decrease (Objective-)C usage.
Also:
- opinions on the nicety of Objective-C differ (but the only arguments I’ve heard why it would be bad more or less are “I don’t like the syntax” and “it’s verbose”, both of which, IMO, are weak. Both, IMO, are acquired tastes. I don’t think anybody is born preferring terse K&R C, for example.
- as you probably know, work is being done on C++ interop (https://github.com/apple/swift/blob/main/docs/CppInteroperab...), so that may improve.
I asked this many times over the years, even in this thread [1]. Still no concrete answer. I still think overall it is a distraction.
So Apple needed a nice language with C-like syntax to woo developers.
NSString *string1 = @"Some";
NSString *string2 = @" string";
NSString \*string3 = [string1 stringByAppendingString:string2];
For sake it was built nearly 40 years ago. Not sure if there's any room to question why Apple and devs wanted a new language.
I was amazed why anyone would want to use this language before Swift but people didn't have a choice.
There were efforts like MacRuby.
https://www.mikeash.com/pyblog/friday-qa-2015-11-06-why-is-s...
It is amazing that people forget to simply use the right tool for the right job and blame the PL instead.
Because a dependent type is a type that represents a computation. A word that symbolises a computation, a word which can be manipulated by hand and assured by machine – and vice versa.
Software is automation. Types are signifiers of meaning. Dependent types are the automation of the automation.
Using a dependently-typed language feels like handling a machine which is the result of having closed a fundamental loop of expression vs. meaning. And that is what it is.
It’s very philosophical-sounding! It has its roots in philosophy – in intuitionism, where math dug down and met philosophers who had dug down from the other side. Kind of.
Practically, the upshot is that things actually become simpler. Kind of because you can grip the tool everywhere. Un-dependently typed languages feel kind of like they’re part tool, part void. You usually can’t express things relating the context you’re in, or looking at.
(As I see it – at least these days – dependent types just are. It’s very, very nice to just have higher-order unification and the things that sort of fall naturally out of having it.)
I found this talk from Xavier Leroy a while back too: http://www.cs.ox.ac.uk/ralf.hinze/WG2.8/26/slides/xavier.pdf. He is the main person behind CompCert, the formally verified C compiler. They do that verification in Coq, so I was expecting him to be a believer of dependent types. But he had this to say:
“ Dependent types work great to automatically propagate invariants
- Attached to data structures (standard); - In conjunction with monads (new!).
In most other cases, plain functions + separate theorems about them are generally more convenient.”
For that reason I prefer Isabelle/HOL as a theorem prover. The core logic is simpler, but you can express whatever you want as a theorem, without worrying about phrasing it within the type system. It feels a lot more natural.
That’s not without downside either of course. Proofs in Isabelle notoriously must match the structure of the code being verified, so changes to the code require proof changes. Liam O’Connor wrote an example of where they he feels dependent types are better here: http://liamoc.net/posts/2015-08-23-verified-compiler/index.h....
Even with that, I’d rather have simple code plus simple propositions with complexity at the proof level. This will likely be another eternal holy war though.
It helps me see what I think I’m seeing, or rather to define it. It also has helped me to perspectives I hadn’t seen.
I’m coming to dependent types from here: “simple, clear code good yes program program argh I can’t express a very distinct thought without escaping to another language layer or generating code using string concatenation”, and from here: “my data structure is simple and clear but argh it needs a handwritten parser and serializer and it needs to be maintained and argh why am I writing a parser AND a serializer it should be just one bidirectional definition? and argh why do I need to write it for each output/input format?”, and from here: “my code is simple and clean and my variables are well named and my tests are well defined and my documentation is well written but argh why can’t I just fold the mechanics that the tests define into the code? as proofs? (and… argh? why can’t my variables and documentation and method names be checked against the code?)”.
It’s metaprogramming that I’m thinking about. And most programming ought to be programming. But we definitely need metaprogramming, and it needs to be understandable and composable and simple and clear. And I don’t know if dependent types are a complete solution to that, but I do think that they are necessary for it.
That-which-is dependent types, which by definition is a computation of what it is and is a proof of what it is. Those philosophical terms finally become practically grounded and practical help in a lot of the work I find myself doing.
I’ll certainly look for the false idol too! My sincere thanks.
> Software is automation.
Wider question: How can a language and its core library stand still? To me, standing still is death for any computer programming language ecosystem. Many languages are just getting started on the idea of "green threads" and "colours" (sync vs async). Some of this can be done purely with a core library using existing language features, but some evolutions are better done with language features.
> How can a language and its core library stand still
I guess by having a more abstract foundation and relying less on adding hacks like colored function? Haskell seems to be like that.
Another thing is language extensions that you have to turn on to use. This makes deprecating stuff easier in the future, so languages can trim itself instead of keep growing.
Looking forward to C# 11 code.
I would almost never write C++ (in the context of low level and performance-relevant code; I write a lot of things for a lot of stuff) if the type system was a touch more rigorous (why can't I specify, and have the compiler yell at me if I don't properly handle, "this pointer may never be null"? TypeScript can do this kind of type narrowing in its sleep!) and if error handling/lifecycle cleanup wasn't hazardous (I'm not even saying exceptions and try-catch, just make it easier to guarantee that a cleanup clause gets called when leaving scope, like Ruby's def-ensure-end).
As it is, whenever I finally hit the breaking point with C++ (which I write mostly from inertia because I know it pretty well) it's probably Rust for me.
I am a fan of Rust, but I am not 100% sold on it. The safety features and ADT's are nice, but I find it quite clunky in practice, and it is just such a huge language full of so many features. It almost feels more like a test language to try the concept of static memory management than a properly designed language in some ways.
I feel it's missing the quality from C/C++ that they are a very thin abstraction over assembly.
Read [0] for a comparison among Zig, D, Rust, and C++, and read [1] for a deeper look at the language's goals. I personally really love Zig's type system [2], with a system for generics that is very simple and consistent.
[0]: https://ziglang.org/learn/why_zig_rust_d_cpp/
[1]: https://ziglang.org/learn/overview/
[2]: https://nathancraddock.com/blog/consistency-in-zigs-type-sys...
We knew about many of these features then, when C was created - but it wasn't until the 2000's really where computing horsepower caught up to be able to use them in a universal way.
I think this statement implies that it’s clear and obvious what assembly will be generated from a snippet of C/C++ code. But few people can understand everything that optimising compilers and modern processors do to normal looking code. An example of this lack of knowledge is seeing people disagree on if a snippet contains UB or not.
If C is so simple, why do people struggle to write it?
Well when I'm talking about an abstraction over assembly I'm not talking about optimizing compilers. That's another topic entirely. What I mean is, if you look at a block of C code, it's very easy to understand what the machine is doing.
> If C is so simple, why do people struggle to write it?
Do they? I think people struggle to write correct, bug-free code in C, but that's because it doesn't save you from yourself, and it's happy to let you do whatever the hardware will do. That's a much larger programmable space than the set of all safe correct programs.
But I don't think people in general have difficulty looking at a snippet of C code and understanding it.
So they simultaneously understand what the machine is doing but don’t know what assembly will be generated? Both can’t be true.
If everyone understood what the machine was doing, everyone would be able to look at a snippet and agree - “that’s UB, let’s not do that”. But they can’t agree. Because few people understand what the compiler and the processor will do.
The “thin layer of assembly” was true for the first generation of C compilers. But it hasn’t been true for a long time. It’s a complete black box now. Anyone who thinks that it’s straightforward isn’t being upfront with themselves.
I mean I can understand a reasonable mapping to what the un-optimized assembly would be. Compiler optimization is very complex, and is going to obscure the results in every language.
> If everyone understood what the machine was doing, everyone would be able to look at a snippet and agree - “that’s UB, let’s not do that”. But they can’t agree. Because few people understand what the compiler and the processor will do.
What? I think everyone can agree that UB is much harder to detect in assembly than in higher level languages than assembly, and assembly gives the most clear view of what the machine is doing. It's a very complex topic to create a system which detects and disallows UB automatically in the compiler - this requires a lot more complexity than a simple mapping of high level instructions to machine instructions.
> The “thin layer of assembly” was true for the first generation of C compilers. But it hasn’t been true for a long time. It’s a complete black box now. Anyone who thinks that it’s straightforward isn’t being upfront with themselves.
I don't know, seems pretty straightforward to me: https://godbolt.org
Can you look at a non trivial C code base and make such an assertion? You can’t. Even simple looking C code could be translated into problematic assembly because such a transformation is technically valid. And it’s beyond the ability of anyone but an expert to guard against that.
C is a very useful language. Very important. Very fast. A great tool in the right hands. The world wouldn’t run without it. And it will remain useful and important and fast for decades to come, certainly. But it’s not simple and hasn’t been for a long time. Let’s acknowledge that.
Do you agree that this statement implies 2 things
1. The compiler isn’t doing anything unusual or unexpected. It applies only basic, easily understandable transformations from C to assembly
2. An intermediate C programmer would be able to guess correctly most of the time what the generated assembly would look like. And thanks to this, such a programmer would be able to avoid most footguns.
But the compiler does unusual/unexpected things, and it’s hard to guess what assembly will be generated or what that assembly does, it’s not a “thin abstraction”. Would you agree?
I think a better metric is: an average CS grad with a little bit of background in compilers and assembly could reasonably be expected to be able to write a naive C compiler which covers say 80% of the footprint of the core language on their own in a matter of weeks.
What do you think is the size of the cohort of people who could write a naive Rust compiler, with borrow checking, ADT's, traits and non-lexical lifetimes? Even without some of the fancy bits like async you're already talking about grad level CS topics at the very least.
I don't find the idea of a new non-memory-safe C replacement in 2022 very exciting. We should be moving away as an industry from non-memory-safe languages, for the obvious security and productivity reasons.
And if you index into an array in C, that's basically like saying `root memory location + stride * index`. In Rust it's calling a trait function which could be doing arbitrary work.
Rust and C++ are on similar levels of abstraction, but C is much, much simpler.
And it's certainly true that Rust has overloading and C doesn't, but that wasn't what I was getting at. The point is that C is defined in terms of the C virtual machine, not the underlying hardware. The C virtual machine is quite far from the actual CPU instructions.
Rust is clearly not at a higher level of abstraction than C++, yet in your own argument you've put C and C++ on the same ground…
> I feel it's missing the quality from C/C++ that they are a very thin abstraction over assembly.
> Rust and C++ are on similar levels of abstraction, but C is much, much simpler.
We can argue the thinkness (or the thinness) of the abstraction until cows come home, but
while (*dst++ = *src++) ;
L1:
movb @(r0)+, @(r1)+
tstb (r0)
bne L1
*ptr &= 1;
and #1, (r0)
C++ is much less of a hardware abstraction, specifically when it comes to the higher level language features.
Or 8 bit CPUs like 6502 and Z80 that aren't even able to fully support C.
Yes – historically – C has never been a perfect fit for 8-bit architectures as it had been conceived for a 16-bit architecture. So what? There are C compilers for 68HC08 68HC11 MCU's as well.
Yet, C has outlived «many languages offering the same "low level" capabilities of C».
You can do so easily. A reference is a pointer that is never null.
>I would almost never write C++ …
Edit: nevermind, I missed the point! GP is saying he wouldn’t write C++ if C supported these features.
This isn't even theoretically true:
void blah(int &x) { x++; }
int main() {
int *x = NULL;
blah(*x);
}
So it will crash, whether that's undefined behaviour or not. The thing at issue here is that other languages have reference types that are more strictly statically guaranteed to be non-null. My point is that references are not a substitute for those, because holding them wrong is not only easy, it's extremely likely to happen in code of any reasonable complixity that mixes pointers and references (ie. almost all production C++ code).
C23 is about to
- add keywords that was valid identifiers before
- remove K&R parameter syntax
- change semantics of the most popular function argument list declaration
- forbid representations other than 2's complement