• 0 Posts
  • 13 Comments
Joined 2 years ago
cake
Cake day: June 18th, 2023

help-circle
rss


  • I definitely agree on the last point. Personally I like languages where I can get the compiler to check a lot more of my reasoning, but I still want to be able to use all the memory management techniques that people use in C.

    I remember Jonathan Blow did a fairly rambling stream of consciousness talk on his criticisms of Rust, and it was largely written off as “old man yells at clouds”, but I tried to make sense of what he was saying and eventually realised he had a lot of good points.

    I think it was this one: https://m.youtube.com/watch?v=4t1K66dMhWk


  • That’s what std::move does, and you’re right that it’s quite an ugly hack to deal with C++ legacy mistakes that C doesn’t have.

    I say move semantics to refer to the broader concept, which exists to make manual memory management safer and easier to get right. It’s also a core feature of Rust.

    Also I’m talking about parametric polymorphism, not subtype polymorphism. So I mean things like lists, queues and maps which can be specialised for the element type. That’s what I can’t imagine living without.


  • I would have said the same thing a few years ago, but after writing C++ professionally for a while I have to grudgingly admit that most of the new features are very useful for writing simpler code.

    A few are still infuriating though, and I still consider the language an abomination. It has too many awful legacy problems that can never be fixed.


  • The only conceivable way to avoid pointers in C is by using indices into arrays, which have the exact same set of problems that pointers do because array indexing and pointer dereferencing are the same thing. If anything array indexing is slightly worse, because the index doesn’t carry a type.

    Also you’re ignoring a whole host of other problems in C. Most notably unions.

    People say that “you only need to learn pointers”, but that’s not a real thing you can do. It’s like saying it’s easy to write correct brainfuck because the language spec is so small. The exact opposite is true.


  • I’m not a fan of C++, but move semantics seem very clearly like a solution to a problem that C invented.

    Though to be honest I could live with manual memory management. What I really don’t understand is how anyone can bear to use C after rewriting the same monomorphic collection type for the 20th time.



  • The specifics of C’s design could barely be less important. In the 70s it was one of countless ALGOL derivatives churned out on-demand to support R&D projects like Unix.

    Unix succeeded, but it could have been written in any of these languages. The C design process was governed by the difficulty of compiler implementation; everyone was copying ALGOL 68 but some of the features took too long to implement. If Dennis Ritchie had an extra free weekend in 1972, C might have a module system. But he didn’t, so it doesn’t.


  • For 99% of use cases this string pool is just slower. Whether intentionally or not, the benchmark code is strange and misleading.

    String and StringPool are only slower in the final benchmark because doing 100,000 allocations in a synchronous loop while retaining a reference to each one is the worst case scenario for a generational GC. It forcibly and artificially breaks the generational hypothesis.

    Conversely, caching 100,000 samples of the same 16 strings (!!!) is the best possible case for the string pool. It spends zero time in GC because the benchmark code contains this very unrealistic pattern.

    Most real code is going to quickly forget intermediate strings and clean them up very cheaply in the nursery generation. If you do need to sample 100,000 substrings in a synchronous loop, you can just use ReadOnlySpan.

    There are real use-cases for string caches and tries, but they are pretty rare.