No, you can just write D. It'll have the same performance as C, if you write C-like code. It might have better performance than C if you use templates (just like in C++).
Not necessarily, you can just call the functions in the C library from D as you'd call them from C or C++ with the added benefit of being able to leverage the D GC, RAII, macros etc.
Dunno about the Debian benchmarks game or their build environment. I did my own benchmarks and it was quite easy to write working D code compared to C, C++ or Rust. I used LDC, the LLVM D compliler as opposed to DMD. Dub is not that seamless compared to Cargo but given that you have to set things up manually, it doesn't encourage dependency hell.
If you're writing networking code, Go is probably a better choice than vibe.d.
You can use C but you are not forced to. In fact, you can write C and convert it automatically to D (though it will need some amount of manual editing afterwards). C is supported as a syntax option but it's still the same compiler for both under the hood. As rightly pointed out by the user above, you can write the same high performance code in the D syntax. The reverse is not true, though -- using high level concepts like classes and GC allocation is not supported in the C syntax.
Yeah and I would say they're probably a better choice for vibe coding than C!
But most of them don't have a nice strong type system like Rust. I have vibe coded some OCaml and that seems to work pretty well but I wouldn't want to use OCaml for other reasons.
I hear this about both Haskell and Rust, and yet, when I tried both in the former I wrote a useless program because I didn't handle state (and yet passed all tests!) while in the latter I immediately wrote a deadlock.
Because it is also possible to write tests that don't adequately capture real-life requirements.
It was an MQTT server, and the tests basically went "if we have these subscriptions, then...", but no subscriptions ever got actually stored by the server.
I prefer the slogan without "probably", "If it compiles it works", because then at least it's clear it's a slogan and not a formal claim. Everyone knows that if you write
multiply x y = x + y
then it will compile but not work, so they don't take it literally. But it is a pithy statement of the lived experience of many users of strongly typed programming, which is more accurately described by something like "if it compiles then it will probably do something at least basically sensible and often be pretty close to what you actually wanted".
I made the same comment last week upon learning of a redis clone entirely vibe coded in IIRC ~70k lines of Rust. Why Rust? Why does a computer need a memory safe language?
Wouldn't the instance state here be "was constructed"? That is: you should always be able to call `Read` because the constructor opened the file, and you shouldn't have to call `Close` anyway because the destructor did.
What "most things" are these?
reply