41–50 of 360 posts
This is a great idea. I maintain that Ada is a better "better C" than any of the alternatives I've looked into, but it has an obvious big hurdle: while it has approximately the same use cases as C, it is completely different in terms of looks and handling. One of the strong points of D is that it still seems very much like C. Very good call to emphasise this.
Walter here - AMA!
Do you know of use of “BetterC” in real-life (i.e: for non-pet projects)? It would be interesting to hear about some real use cases.
Earlier quoted context omitted.
Mine is Zig.
Are you aware of anyone with large projects in Zig? I'm curious how fast it compiles, given in my view faster compilation is one of the biggest advantages of D over C++ and Rust, due to it having a lightweight compiler, DMD. Zig seems to still use LLVM, like Rust, which is relatively slow.
https://www.twitch.tv/videos/602715503 [edit: at 10:20]
Then again, I am biased.
- enumerate everything C is doing bad.
- presents fixes with a full bag of unnecessary features that no c programmer wants.
I wonder why there is no "Fixed C".
Walter here - AMA!
Hi Walter, Thanks for doing this AMA! Is "Better C" Done? Or are there any features/changes being planned? Will it always stay backward compatible?
This is a great idea. I maintain that Ada is a better "better C" than any of the alternatives I've looked into, but it has an obvious big hurdle: while it has approximately the same use cases as C, it is completely different in terms of looks and handling. One of the strong points of D is that it still seems very much like C. Very good call to emphasise this.
One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…
>so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Especially given that D functions like "map" and "reduce" tend to return special iterator types so that the compiler is able to smarty fuse them where possible. If D had concepts l…
One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…
>so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Especially given that D functions like "map" and "reduce" tend to return special iterator types so that the compiler is able to smarty fuse them where possible. If D had concepts l…
Of course it is. Map's type is "(a -> b) -> [a] -> [b]". D just absolutely and completely failed here, despite this being a solved problem 40 years ago.
Walter here - AMA!
Hi Walter. I have two and a half questions: * Regarding the syntax of 'lazy'. It seems to me that it would make for better readability if the lazy keyword were required at the callsite, along the lines of doStuff(lazy getValueUsingExpensiveComputation()); rather than the current syntax where it's not clear at the callsite which, if any, of the arguments are lazy. C# does something similar with ref . What's the thinki…