Hacker News Reader

Comment by softirq | Hacker News Reader

After writing primarily no standard library C for 15 years, I have to say that I find Rust just as ugly and cumbersome as C++ (not debating its safety guarantees). It seems like languages that add sufficiently advanced type/macros systems always spiral into unwieldy beasts where you spend a bunch of your time arguing with the type systems and writing blog posts about some new piece of type theory to solve a problem you would have never have had with C. People just get greedier with deriving code and wanting more "magic" until every program only makes sense to its author.

I don't think I will ever like kitchen sink languages. Experience has taught me that the most effective tool is the simplest one, which for most use cases today would be Go. For systems programming I just shudder to think how convoluted and hard to read things will become when we take already extremely complex code written in the simplest terms in C and port it to Rust.

View on HN

> I have to say that I find Rust just as ugly and cumbersome as C++

Ok, so you don't like it aesthetically. Do you have problems writing unmaintainable software in it? What about incorrect software? Is there any specific feature in the language that you object to that will cause confusion and lead to people writing bugs?

C is a very beautiful and "simple" language, people also write a lot of security vulnerabilities with it.

Beauty is a useless concept in a programing language. Most of the time it just relates to someone's bias towards what they are familiar with. A lot of people find Python "beautiful", I'm unfortunately very familiar with python and as I've become more and more familiar with it I find it uglier and uglier.

Same with C, I remember all the many hours I've spent in valgrind debugging problems other people have made for me and I find it ugly too.

When I look at a programming language, I don't think about aesthetic "beauty" or even "simplicity".

I think, does this programming language allow me to represent the concepts I want to represent accurately and correctly?

If it is not memory safe, does not support static typing with algebraic data types, and does not have null safety it does not meet those minimum requirements and is not suitable for use.

Edit: I want to add, it's not just accuracy and correctness that are important. Performance is very important too and many functional languages absolutely flounder because of strict immutability and the adoption of patterns that have terrible memory access patterns.

It isn't a question of aesthetics, the primary pragmatic issue with languages that have many features is how hard it can be to read a new code base. Tools like macros and traits can save you a lot of typing but when someone else comes into your code, it is much harder to come to terms with it than simpler languages like C or Go where the set of features can all be held in your head and the actual code is explicitly stated rather than generated by macros and generics and such.

This is a natural tradeoff in language design, do you deal with verbosity and boilerplate because the language has few features, or do you deal with the cognitive overhead of understanding all the features?

I find Rust extremely easy to read. In comparison, I was trying to read a Go codebase and found it hard to read. Of course, I've spent multiple years writing Rust and almost no time writing Go and I don't know the Go programming language at all. It was very easy to "learn" of course. But I didn't actually learn it given when I started reading code bases I was interested in I started to see weird things like

`var _ litestream.ReplicaClient = (*ReplicaClient)(nil)`

which I couldn't find an explanation for using normal means so I asked chatgpt and it told me it's an

"interface compliance check" "This line is a way of ensuring that a certain type (*ReplicaClient) implements a certain interface (litestream.ReplicaClient)."

For some reason this pattern was left out of the official documentation. Am I missing other patterns? I find Traits much easier to understand.

Also, like many others I give coding interviews and people writing Go always seem to run into null pointer errors. I'm not making that up. (I have no sample for Rust programmers)

But when all the features of the language fit in your head, it usually means the code you're reading keep repeating itself lacking more convenient features (yes Go, I'm talking about your error handling).

The needs of our programs are complex, so in the end this complexity has to be somewhere, and it is either in the language itself, or in our code…

I think there’s this concept in language theory that those speaking or writing strive for more complex concepts as it matches better their thoughts, while those receiving strive for more simplicity as it takes more energy to make sense of complex concepts (think about it as adapting the language to your audience).

But I think the main problem here is the famous debate of statically-typed languages vs dynamic ones. As statically-typed languages add more and more features to be more expressive, they have to work around the compiler limitations and create very bizarre syntaxes if they want to keep performance.

But maybe this is a tooling problem? What if we could see the code in a simpler way even if the actual code involves macros and templates?

Swift has just implemented macros that Xcode expand to show the generated code in a collapse/expand way, making it easy to understand what it does.

This. Being able to expand macros lets you learn what it does in context, and once you're more familiar with the abstraction it gives you the benefit of hiding the details and highlighting the moving parts within an otherwise static structure.

>But maybe this is a tooling problem? What if we could see the code in a simpler way even if the actual code involves macros and templates?

Intelllij Rust plugin does this.

    println!("Hello, world! {}", x);

    >Recursive expansion of println! macro:
    >{
    >    ::std::io::_print(IntellijRustDollarCrate::format_args_nl!("Hello, world! {}", x));
    >}

C has plenty of macro use doesn’t it? Even something as simple as a doubly linked list is implemented with lots of macros in the Linux kernel AFAIK.

> C or Go where the set of features can all be held in your head and the actual code is explicitly stated rather than generated by macros and generics and such.

The C preprocessor is a Turing-complete, and a lot of C code abuses it to implements things a lot more complex that just "macros and generics and such".

Because of that C with a preprocessor literally has a infinite "set of features", a pretty big set of features almost garanteed to not fit anyone's head. I don't think you can call something with - both by it's own code and it's libraries code - arbitrary turing-complete preprocessing "understandable".

> Beauty is a useless concept in a programing language.

Maybe not aesthetic beauty, but readability in many contexts matters more than performance. Code that isn't readable hides bugs and can't be maintained (FYI Rust doesn't stop you from writing bugs into your code). A language like C or Go where you can fit most of the syntax and mechanisms into your head are simply easier to read and reason about than a language where you need a PhD in type theory to understand one signature.

> If it is not memory safe, does not support static typing with algebraic data types, and does not have null safety it does not meet those minimum requirements and is not suitable for use.

You'd better stop interacting with technology then, because the vast majority of it is still running something compiled from C. We're talking about control systems, life saving technology, technology that's running in outer space.

> Rust doesn't stop you from writing bugs into your code

Obviously. It's not about Rust specifically. It's about accurately representing state which is extremely difficult to do in programming languages that do not have algebraic data types.

In Golang how do I represent that a type is either type A or type B and then in a type safe way perform logic if it's type A or perform logic if it's type B? Algebraic data types also allow for things like the result and option type.

Throw in the borrow checker which prevents a host of aliasing and concurrency bugs (not all). You are more likely to write correct Rust than other languages.

> You'd better stop interacting with technology then, because the vast majority of it is still running something compiled from C.

Thank you for another lesson I already know. I clearly meant I don't think it's suitable for use in new programs. People will still use it regardless as they are free to do so.

> In Golang how do I represent that a type is either type A or type B

generics provide one approach to this, but, in general, you don't -- you find another solution to your problem

> extremely difficult to do in programming languages that do not have algebraic data types.

And this is why people like me avoid ML based languages, type astronauts, and shiny new toys. You're misrepresenting inconveniences as fatal flaws when we've been successfully running all of modern society on kernels written in C for fifty years. Most of the kernel subsystem maintainers aren't even considering Rust as anything more than an experiment at this point. No one cares about ADTs and the perfect representation of state transitions in the type system when we have actual problems to solve, and we can and have been solving them in C.

> And this is why people like me avoid ML based languages, type astronauts, and shiny new toys

Instead you get things like this in GO

`var _ litestream.ReplicaClient = (*ReplicaClient)(nil)`

And every single variable is implicitly Type or null because obviously the alternative is more complex

> And this is why people like me avoid ML based languages, type astronauts, and shiny new toys.

There's nothing new or shiny about the ML family. And the growing interest in ADT's is about their very real advantages in representing state and solving real problems in a less error prone manner than C

Don’t argue with him. He is just and old man doing what all old man do: find excuses to not learn new stuff and convince himself that he didn’t have to do it

Yeah I find it really hard to see how they're being charitable. Just an old fart arguing for the continued relevance of curmudgeon-y technology instead of actually responding to the points being argued.

What people who still care about writing C are doing is starting to use tools to bring some of what Rust offers to C, because they acknowledge that avoiding entire categories of bugs is actually really good, despite which language you use. But... no mention of that here, it seems.

> successfully running all of modern society on kernels written in C for fifty years.

No we haven't. C is successful despite its major flaws (seg faults based on memory errors are not mere "inconveniences"). Microsoft mentioned for example that around 25-33% of all bugs in Windows were based on memory errors. They are currently cutting those down to 0% via Rust.

> FYI Rust doesn't stop you from writing bugs into your code

You are committing the perfect solution fallacy [0]. Rust won't make you have no bugs in your code but don't conflate some number of bugs with a reduced number of bugs, a reduction is still a meaningful outcome, otherwise we'd still be writing in assembly.

> We're talking about control systems, life saving technology, technology that's running in outer space.

Indeed, that's why we should use more memory safe languages, because we are dealing with critical systems. Just because they were written in C does not mean that they should continue to be. It's like digging a hole with a stick, and when someone suggests a shovel or backhoe, you mention that all previous holes were made with a stick. There is no relationship between the previous work and what should be done in the future.

[0] https://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_soluti...

> You are committing the perfect solution fallacy.

Rust is also not a perfect solution. You have to prove that the benefits of solving for the bugs Rust can prevent outweighs the downsides of asking a bunch of C experts who are currently developing kernel subsystems in C to stop what they are doing and rewrite millions of lines in C in a language that has very low marketshare in the space and is far, far more complex in terms of abstracting over assembly. People write systems software in C not because they have a fetish for bugs, but because we do in fact still have to stay close to the hardware and not get lost in a minefield of abstractions.

> Rust is also not a perfect solution.

Yes? That's explicitly what I said.

C is successful despite all the bugs, not because of it. If there are newer methodologies that solve bugs, one should use them, rather than sticking to their "tried and true way" while suffering through segmentation faults. Already parts of the Linux kernel as well as Windows are being written in Rust, so if it's good enough for them, it should be good enough for those bunch of C experts. They also don't have to rewrite millions of lines, they can incrementally improve the codebase.

All this to say that even in your above comment you're still committing the perfect solution fallacy. You are still talking about how Rust is not perfect even though no one said it was, and you mention trying to convince all of those C experts to rewrite millions of lines of code when, again, no one said they have to do.

> Already parts of the Linux kernel as well as Windows are being written in Rust, so if it's good enough for them, it should be good enough for those bunch of C experts.

The C experts I was referring to are the subsystem maintainers and none of them are currently working on migrating to Rust AFAIK. So far the work in Linux with Rust has been a few driver rewrites. Keep in mind that there are subsystems like eBPF, io_uring, etc. that are under rapid development and are completely in C. I think if you really believe that kernel code should be written in Rust, you should start submitting patches instead of telling people that they have some sort of moral obligation to use Rust when you aren't the one that has to do any of the work.

You aren't being charitable. Please stop fussing it's rather immature. People have addressed your points, please actually respond to theirs.

It's not helpful to keep saying "look there still some people writing C" and use that as an argument for how C has somehow solved the problem where C programers regardless of how good they are ultimately write bugs that lead to takeover of the program counter. Rust makes the world better. If you don't want to pay the semantic price of that then fine, but it means you're okay with still writing horrible bugs. Some of us aren't. I promise Rust's semantics are better than C++ even though Rust has its rough edges and could be improved.

What would be helpful to your cause is to mention the examples of people starting to add tooling to C to solve problems people are solving with Rust, but without the semantic price of Rust.

> readability in many contexts matters more than performance

I completely, whole heartedly agree. Not just in many, but in most contexts.

And Rust or C shouldn't be used in these contexts. Use typescript or python instead.

C is not what I would call a very readable language. I don’t think you could drop someone who newly learned C and have them be effective looking at glibc for example.

Because of the use or abuse of macros, different C codebases can look very different, and to learn it you have to figure out all the quirky macros. If people stick to standard C with few macros and verbose variable names, it's really not bad.

    void* (*identifier) (void*);

    typedef struct
    {
        /* ... */
    } my_struct_t;


    static return_type
    name_of_function (type *restrict argument)
      {
            int a, b, c;
            /* body */
      }

Just some examples of illegible syntax that's "standard" C. C is not a pretty language. It's small, but it's ugly as sin.

It's nearly impossible to actually parse anything more complex than a pointer to a struct in C because it wasn't written for humans, it is a relic of using a convenient recursive descent parser to parse C's syntax that we end up with `void* (*id) (void*)`...

Readability is a function of familiarity though. I have been programming in Rust for > 5 years, I find it to be an incredibly readable language, because I am so familiar with it.

Are you familiar with the lengths people go to to make C work in the "life saving technology" contexts?

Your argument is essentially: My thinking is clear and correct, I just can't explain to the compiler why it's correct, so just trust me.

People _very_ easily delude themselves into thinking their thinking is clear. When they are forced to spell it out in excruciating detail it often turns out otherwise.

> After writing primarily no standard library C for 15 years, I have to say that I find Rust just as ugly and cumbersome as C++ (not debating its safety guarantees).

The safety guarantees are the whole point compared to C. So what’s the point of complaining about how things are cumbersome when you just elide that whole side of the debate?

I could complain about how C is too cumbersome with the proviso that I don’t care about portability or efficiency. But then what would the point be?

> where you spend a bunch of your time arguing with the type systems

That’s the point. It’s a feature, not a bug.

The type system exists to reduce the space of unsound programs. The trade off is dev time for runtime errors.

Point of higher level languages is and was productivity. Now some languages have Turing complete type systems and I have seen some clever usage of types where really even the author might not know how it works given enough time passes without touching the code base.

There's definitely tradeoffs to some things, and I think in particular Rust's static guarantees can cause additional friction, but in general I've found ML derived languages to be extremely practical because it's a good local maximum on the graph in terms of complexity vs runtime safety (where languages like Java add too much friction without enough benefit compared to something like Python)

I've found in software development the 80/20 rule is extremely true, but when you need something from that last 20%, it can really mess up your architecture trying to work around it. To me this is why others love LISP so much, and I appreciate F#/OCaml for getting me as close to that potential as possible while keeping static analysis reasonable. Clever use of type systems is great for RAD and making sure critical components make certain classes of bugs a compile time error, and it can turn into undecipherable magic, but the additional information and guarantees advanced type systems provide allow me to focus on my immediate problem instead of the interplay with a larger system.

> I don't think I will ever like kitchen sink languages.

What makes a kitchen sink language?

I would describe it as a language where there is more than one strong idiom

For C and Go, there really is only one prevailing idiom on how to write code (for C one could argue that static vs. dynamic allocation are two idioms, and multiple ways of doing concurrency)

For C++, whenever you have the chance to abstract some code into an interface you'll have the choice to create a template or use polymorphism, concurrency can now be done with an event loop, co-routines, threads...

Rust has the same bug/feature where there's more than one idiomatic way of doing things.

I feel like people have been saying this about Go for a while and I don't see how it's true. The only real idioms out of Go are explicit error handling, types implementing interfaces, and the formatter. Otherwise, you can kinda do whatever you want in Go, and I have yet to feel at home reading a Go codebase.

Thank you for the explanation.

“For C…, there really is only one prevailing idiom on how to write code”

You can look at single projects that have changed the way they write C code over time, introducing new idioms all the time. OpenSSL is a perfect example of that in regards to their work to reduce memory related bugs. C’s idioms have changed so many times over it’s life it’s hard to keep track or even read it from one era to the next.

> For C and Go, there really is only one prevailing idiom on how to write code

What’s the one idiomatic idiom in C for a growable list of items? Because I must have a seen a hundred of those in my time.

What’s the one idiomatic idiom in C for a hashmap? I’ve seen about a hundred of those too.

I would think you are referring to implementations of the one prevailing idiom as opposed to seeing multiple idioms for the concept. The idiomatic way to represent a growable list in C is to make a list (using some implementation) and put it in a structure with bookkeeping data, then using that list by passing it (or a pointer to it) to plain old functions to use it.

Of course I'm talking about an idiomatic implementation, what else would I be talking about in this context?

> The idiomatic way to represent a growable list in C is to make a list (using some implementation) and put it in a structure with bookkeeping data, then using that list by passing it (or a pointer to it) to plain old functions to use it.

That sounds like a long-winded way to say "there's no one idiomatic growable list in C".

Having more than one way of doing things is good when it's a consequence of a positive, well-curated language evolution. I think that's Rust case. It doesn't mean that it will become more readable ("beauty"?) in the future, there's a lot of line noise already: <'a>, foo::bar, #[define(...)], etc.

Or, ehem, JS. I think the JavaScript -> ES6,7,8,9 evolution is a good example of positive change: the language improved immensely at the cost of having even more idioms, TIMTOWTDI and transpilers like TS. The old parts are now marked as bad practice and optionally linted to hell. You still have to put up with W3schools-level code once in a awhile though.

Perl and C++ to me would be some bad examples. TIMTOWTDI hampered their evolution way too much. Perl froze for 10 years+. Python was much braver: their folks evolved (from 2 to 3) by breaking compatibility in order to remain true to its Zen.

Zig and Go are examples of rigidity, one-way-only extreme, which is a pain sometimes but, in Zig's case, maybe a good practice for a young language project. Readability in Zig is excellent and I like the choices with the @ functions ie. @as or @ptrToInt() instead of piling-up parens and asterisks. Definitely a case-study of readability and evolution for the future to come.

I don’t think your definition is badly chosen. In fact I think it is a pretty good demarcation between language ideals. However, I would define ‘kitchen sink language’ as one that has a bit of everything in the language itself and has the syntax to ‘support’ those bits of everything. Like a language that has lambdas, functions, methods, type classes, value types, box types, Types of types, macros, lifetimes, templates, multiple looping constructs… the list can go on. I think the real exemplars for ‘kitchen sink’ in this conversation is to differentiate between Go and C++. The amount of concepts in C++ is staggering and Go is in contrast brain dead simple. I think Rust is absolutely on the C++ side of this divide and is primarily what GGP was getting at in their comment.

Bravo!

Reply on news.ycombinator.com