Hacker News Reader

Comment by nynx | Hacker News Reader

C is one of those languages that consistently looks fast, but often is slower than other languages. Without generics, it's difficult to have complex data structures for each type, so you end up with lots of pointer chasing and less than optimal data structures.

View on HN

I want a C with templates (with support for C++20 concepts) and consteval, instead of a C with classes (C++)

I don't care about RAII, so I don't care about the ownership tracking that Rust provides. I like to think that memory management is actually part of the problem, rather than a responsibility for the language's runtime.

I want to generate hundreds of datastructures or algorithms at compile time that are optimal in specific situations using introspection of types.

I want everything else in the language to get out of the way and know that I'm writing code that actually runs on a real computer, not an abstract machine.

Every time I read this, I agree. And then I wonder why people don't do the obvious thing like I do and write C with templates in C++. It is a kitchen-sink multi-paradigm language so just embrace it.

Plus, inheriting abstract interface classes is more convenient than writing a vtable by hand when such a thing makes sense. You don't have to participate in Java-style class voodoo if you don't want to.

I am sure all the other languages mentioned like Rust, Zig, and D are very good too, but C++ is where all the high-performance libraries live, and whatever productivity gains I would get by switching languages is utterly dwarfed by that.

Any argument that starts with "I don't care about safety" is a bad idea.

We could use more safety even, like automatic race condition analysis in language and more.

Conservative extensions of C and C++ exist, and they're not very popular, just check how popular D is...

Sounds like you might like Zig.

Never gave it an honest look, maybe I should spend some time learning it

D is that language, especially wrt to the code generation. Code generation and metaprogramming is what we obsess over.

I am afraid D slowly needs to decide what it wants to be when it grows old.

Can you please elaborate what kind of decision to make on D? It's a general purpose programming language with excellent metaprogramming capability.

As a comparison, has Python decided what it wanted to be? A scripting language like Perl, data processing language like R, tool command language like TCL or web backend programming language like PHP or RoR? But nobody in their right mind will ever say Python need to decide on his direction when it grows old.

As you probably have known when Python is around 20 years old (like D today), it played second or third fiddle to PHP, TCL, Ruby (RoR), Perl and R in their respective domains, and at the time the growing pain into Python 3 is yet to happen. But looks where is it now?

Personally I think the D language foundation is already solid [1]. It just need a killer application for it to be more popular and well-known just like what RoR did to Ruby. And if you have a solid foundation, it will probably just a matter of time for it to properly take off.

[1]https://dl.acm.org/doi/pdf/10.1145/3386323

An excellent language that keeps being rebooted with endless discussions on memory models, incomplete features, DIPs that were half implemented without documentation.

While they don't know where it should go, C#, C++, Swift keep adopting D like features, with their rich ecosystem.

D could have been C# on Unity, given Remedy experience with the language, instead not.

D's Metaprogramming was great 10 years ago, not when placed against C++20 metaprogramming, or the features arriving in C++23.

Don't you think it's a good thing to have choices of managed memory and not, or mix them together when necessary? I think it's a paradigm shift in programming for the better.

Programming languages used to stick to one programming concept for examples either imperative, functional or object oriented. But now most modern languages support at least more than two concepts to stay relevant.

Regarding other languages later adopting D like features, sure you can do that but the end results will probably be sub-optimal and clunky. For example, Python adopting array processing in Numpy library and becoming very useful and popular, but it will not be as seamless, intuitive and natural as R or Fortran array processing capabilities.

It is good to have choices, provided they are fully implemented and bug free, instead of jumping into the next possible solution.

Phobos still doesn't fully work with @nogc, DIP1000 is undocumented and now there is @life getting the spotlight, meanwhile the GC is stuck in early 2000 design, the std.allocators library is in experimental limbo for years.

Even if the results are cluky, they can double down on an eco-system in libraries, IDE tooling and OS support, that D lacks.

Currently the motto is Jack of all trades, master of none.

We are having a meeting to lay down a plan on memory safety in 2 hours time, so have faith.

Also DIP1000 isn't that badly documented these days, not brilliantly, but frankly I find that a lot of complaints come from people who weren't ready (this doesn't necessarily apply to you in particular, just that these attitudes spread) to understand it in the first place.

And what do you mean by OS support? I find that not many other languages take it as seriously as us?

Looking forward to the outcome.

Taking C# as example, I mean being able to do embedded stuff (Meadows, IoT Core), regular desktops, IBM mainframes, game consoles, and mobile OSes, without having to create my own compiler toolchain and self made druntime.

Like what? The company I work for has business logic, numerical code, a functional DSL, bindings to just about everything needed, fast and introspectable because they are under the same language.

Which features do you recommend we deprecate?

It is more like finalize the unstable features, stop chasing other languages memory models, fix type system holes, no incomplete DIP implementations.

you can abuse the preprocessor to do efficient generic programming e.g:

https://github.com/attractivechaos/klib/blob/master/khash.h

https://github.com/attractivechaos/klib/blob/master/kvec.h

FWIW writing a generic vector like that ^^^ is going to be faster than almost any std::vector implementation you can find. And that is just one way to do it, there are other tricks.

Good luck writing a data structure more complex than a vector, like a b* tree, with that approach.

How would writing a B*-tree be any harder?

The actual logic of a B*-tree would be equally hard in any language. The macroized template part is easy.

Reply on news.ycombinator.com