Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

D as a Better C

dlang.org

Post reply on HN
Print view View original

31–40 of 193 posts

Re: D as a Better C

#31

Post by skymuse »

christophilus wrote: post #14

I tinkered with D a bit (along with Nim, Dart, and C as a comparison) while writing a Clojure interpreter. D seems to be a nice language, but I found the editor integration wasn't the best. I also found it annoying that the docs used `auto` all the time, so you could never figure out the right type annotations for their APIs (e.g. I want to call the foo API and return its value from my method, but the docs all use `a…

Idk about the editor integration problem, but usually when I run into the 'auto' problem what helps me is printing out the type as follows:

typeof(var).stringof.writeln;

Re: D as a Better C

#32

Post by lambda »

christophilus wrote: post #23
logicallee wrote: post #17

Earlier quoted context omitted.

>Nim, Dart, and C as a comparison) Could I ask about your thoughts regarding Go (which has much less syntax and fewer features than all of the above). Have you looked into it?

Yeah. It should have been in that list, actually. I wanted to like Go. It seems simple (which is what I like so much about Clojure), but honestly, I found it to be frustrating for all the standard reasons the Go team is tired of hearing (e.g. no generics, error handling littering my code and obscuring intent, etc). In fact, I think Go doesn't quite deserve the reputation it has as being a simple language. It's a fami…

Have you looked at Rust? It uses Option types, has generics, also uses return values for error handling but has a lot more syntactic sugar to make it cleaner than in Go.

Re: D as a Better C

#33

Post by WalterBright »

christophilus wrote: post #14

I tinkered with D a bit (along with Nim, Dart, and C as a comparison) while writing a Clojure interpreter. D seems to be a nice language, but I found the editor integration wasn't the best. I also found it annoying that the docs used `auto` all the time, so you could never figure out the right type annotations for their APIs (e.g. I want to call the foo API and return its value from my method, but the docs all use `a…

There's some debate about where is the sweet spot in the use of `auto` between self documentation and minimizing refactoring costs.

Fortunately, the programmer gets to decide which to use.

Re: D as a Better C

#34

Post by zombinedev »

christophilus wrote: post #14

I tinkered with D a bit (along with Nim, Dart, and C as a comparison) while writing a Clojure interpreter. D seems to be a nice language, but I found the editor integration wasn't the best. I also found it annoying that the docs used `auto` all the time, so you could never figure out the right type annotations for their APIs (e.g. I want to call the foo API and return its value from my method, but the docs all use `a…

Can you compare your D vs Nim experience in more detail? What are the key points that you like better about Nim?

Re: D as a Better C

#36

Post by 0xdeadbeefbabe »

saghm wrote: post #15
new299 wrote: post #6

Earlier quoted context omitted.

I really really don't been to pile on Python... but every time I've had to interact with it I've been shocked at how slow it is compared with C or C++. I tend to write scientific code to process datasets in the range on 10Gb, for simple operations Python code can take hours as opposed to just taking minutes or seconds in C. I'm sure it's possible to write more highly optimized code in Python, but it never seems to be…

Python is a high-level interpreted language, and C/C++ are low-level (even compared to other) compiled languages. While you might be able to optimize your Python code to run faster than it does now, it's never going to match the performance of C/C++, nor is it intended to. Go will be a significant speedup over Python, but likely won't quite match the speed of C/C++ for most tasks. Then again, the ease of development…

> Go will be a significant speedup over Python, but likely won't quite match the speed of C/C++ for most tasks. Then again, the ease of development in Go will likely be noticeably better than in C or C++.

In my experience, you don't mean: learn to make C and C++ development just as easy as Go development and enjoy the best of both worlds.

I agree with you, but it seems illogical on the surface.

Re: D as a Better C

#37

Post by WalterBright »

Shorel wrote: post #11
systems wrote: post #2

D is betting hard on memory safety, and apparently system programming honestly i think, had they gone in the direction of D as a better Python, and application development, they would have made bigger wins (in terms of popularity) ... better tooling, better ide, refactoring, better GC, better libraries ... better faster programs

The only difference I see is in marketing. D could be marketed as a better Python and it has enough features to qualify.

There are many D programmers who use D as a fast Python.

Re: D as a Better C

#38

Post by zombinedev »

Ace17 wrote: post #35

Why remove RAII? It's not fundamentally incompatible with "Better C" semantics, especially if there are no exceptions.

RAII in not removed by design. It is just work in progress. It will be added to -betterC when its implementation is more mature for this mode.

Re: D as a Better C

#39

Post by MichaelBurge »

If I'm writing C, it's usually a small module or algorithm that I link into another language. Since D is supposed to be in gcc now, I wonder if it's reasonable to start including D code in e.g. Perl or Ruby or Haskell libraries.

The great thing about C is once you write it, you never really have to worry about the language changing 15 years down-the-line and breaking your code. The GNU version might have a similar property, since GNU tools stay around for a long time.

Post reply on HN