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

81–90 of 193 posts

Re: D as a Better C

#81

Post by srcmap »

I love to see someone prove D as a Better C by porting the "small" sqlite 124K line of C code to D and run some benchmark/test code against it.

I used to work on OO database engine that handles billions of records.

I end up rewriting/overloading my own new/delete and redesign everything how data is load/store around it. Shorten the open/close document time from hours to seconds for large documents.

Basically, one can easily mmap billions of records directly into data structures accessible by C API easily in a few ms. One can dispose billions of records also in a few ms. I saw similar design patterns from the sqlite code base.

Language with memory safety (GC) design in mind won't allow anything like that as far as I know.

I love to see some D experts prove me wrong.

Re: D as a Better C

#82

Post by pjmlp »

kibwen wrote: post #53
pmoriarty wrote: post #42

Earlier quoted context omitted.

It is up to the implementation of a language whether that language is compiled or interpreted. For instance, there are C interpreters and Python compilers. Neither language is limited to being one or the other. It's just that usually people use C compilers and Python interpreters, but there's nothing inherent in those languages that limits them to those. It's all up to the implementation.

This is true, but not always in a useful sense. There exist language features whose semantics are expressly dynamic, and if your language includes those features it will frustrate static compilation. For example, if your language includes `eval` (as Python does), then any precompiled binary would also need to include a complete Python interpreter. This is why efforts to compile Python (and other languages that are tr…

Which is why for me the best way is to be able to choose between JIT/AOT deployments, instead of a plain interpreter.

Maybe one day PyPy will finally become the default option.

Re: D as a Better C

#83

Post by pjmlp »

vram22 wrote: post #54
nindalf wrote: post #3

Earlier quoted context omitted.

The better Python market isn't an easy one to crack because its a bit crowded. Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Python itself is improving rapidly, for example with the addition of Type Hints. Its pretty difficult to be a better Python in 2017. The better C market, on the other hand, hasn't seen any real…

>Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Also fast compilation, which D also has.

Most Algol derived languages have it, it became a lost art as C and C++ pushed them aside.

Re: D as a Better C

#84

Post by steveklabnik »

christophilus wrote: post #76
lambda wrote: post #32

Earlier quoted context omitted.

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.

I have tried Rust in the past, though not on this particular hobby project (my Clojure interpreter). I found it hard to get into, and I've gotten into a lot of languages in my time-- some of which are considered challenging (e.g. Haskell). With Rust, I always felt I spent too much time wrestling with it, and not enough time being productive. I imagine that you hit a threshold at some point and that begins to change.…

Rust's major goals this year are around learnability and productivity; maybe come check it out again someday :)

Re: D as a Better C

#85

Post by WalterBright »

millstone wrote: post #66
WalterBright wrote: post #47

Earlier quoted context omitted.

RAII requires exceptions to be correct. I hesitate to say it it has RAII otherwise. Exceptions have two issues: 1. D exceptions currently require the GC. There is a Pull Request to fix that, but it isn't incorporated yet. 2. More problematic is the Dwarf exception handling mechanism requires a language specific "personality" handler. This is supplied by the D runtime library. Trying to trick the C runtime library one…

Why does RAII require exceptions? RAII is routinely used in C++ with -fno-exceptions.

Because D code may sit in between code that throws and exception and code that handles it. Without EH support, the RAII destructor won't get called when the stack is unwound.

Re: D as a Better C

#86

Post by cstrahan »

logicallee wrote: post #62
christophilus wrote: post #23

Earlier quoted context omitted.

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…

EDIT: this is getting downvotes for some reason even though it's just addressed to OP. OP, you could email me at the link on my profile if you didn't want to answer here. I'm not on the Go team or anything, just curious. --- Thanks for your answers! So I know you don't want to rehash what's easy to find elsewhere, but your perspective is different because you wrote a Clojure interpreter. It's not the same as what I c…

I'll let the parent answer you (though I have similar sentiments as someone with language implementation experience, and FWIW, I have professional experience with Go, Ruby, JavaScript, Clojure, C#, and I've used Haskell, F#, and much more in my free time).

I will, however, point out that you're likely using a different definition of simple ("easily understood or done; presenting no difficulty. ") than is often used in technical circles ("composed of a single element; not compound"). Simplicity and ease are distinct, and one does not necessarily imply the other; it's not hard to find convoluted designs that feel easy due to familiarity, while a much smaller, consistent design will feel difficult because the concepts (while fewer in number) are foreign.

Rich Hickey (creator of Clojure) gave a great talk on easy vs simple: https://www.youtube.com/watch?v=rI8tNMsozo0

Here's something familiar to most professional web developers: JavaScript.

But it's also complicated: https://www.destroyallsoftware.com/talks/wat

Here's the spec: https://www.ecma-international.org/ecma-262/8.0/index.html

And here's something unfamiliar and often considered difficult: lambda calculus.

And yet it's very simple. Here's the entire definition of lambda expressions (lifted from Wikipedia):

---

Lambda expressions are composed of:

* variables v1, v2, ..., vn, ...

* the abstraction symbols lambda 'λ' and dot '.'

* parentheses ( )

The set of lambda expressions, Λ, can be defined inductively:

1. If x is a variable, then x ∈ Λ

2. If x is a variable and M ∈ Λ, then (λx.M) ∈ Λ

3. If M, N ∈ Λ, then (M N) ∈ Λ

Instances of rule 2 are known as abstractions and instances of rule 3 are known as applications.

---

So, while JavaScript programmers might find the lambda calculus unapproachable, it would be difficult to argue that the former has fewer gotchas than the latter, as the former is wildly complicated and the latter is so simple that you could fit its definition on business card. Once you appreciate the difference between simplicity and ease you can better evaluate your options, as it might be worth investing time in learning an intimidating, foreign solution if you believe that it will provide better stability/correctness guarantees/etc. Also, simple things are generally easier to work with compared to complex things assuming a similar degree of experience -- so investing in unfamiliar-yet-simple things will often save you a lot of effort in the long run. Strictly adhering to familiar things is a recipe for being stuck in a local optimum.

To take this full circle, Go being easy doesn't mean that it's simple.

Re: D as a Better C

#87

Post by WalterBright »

vram22 wrote: post #58
saghm wrote: post #13

Earlier quoted context omitted.

According to their respective Wikipedia articles, D is 8 years older than Go. Given that you're saying that Go had a lot of success breaking into the Python market, why couldn't D have instead if they had put their efforts there from the beginning?

>According to their respective Wikipedia articles, D is 8 years older than Go. And Go itself is some years old now (created in either 2007 or 2009 - according to its Wikipedia article - maybe they mean initial creation and first release for public use, by those two year values). So Go is about either 8 or 10 years old. And that makes D either 16 or 18 years old. >Go had a lot of success breaking into the Python marke…

I've always been attracted to systems programming, and it's what I know best. Hence D is angled that way.

Re: D as a Better C

#88

Post by steveklabnik »

> What may be initially most important to C programmers is memory safety in the form of array overflow checking, no more stray pointers into expired stack frames, and guaranteed initialization of locals.

Are there any docs about this anywhere? http://dlang.org/spec/betterc.html doesn't really describe this stuff.

Re: D as a Better C

#89

Post by WalterBright »

andrewflnr wrote: post #64
WalterBright wrote: post #47

Earlier quoted context omitted.

RAII requires exceptions to be correct. I hesitate to say it it has RAII otherwise. Exceptions have two issues: 1. D exceptions currently require the GC. There is a Pull Request to fix that, but it isn't incorporated yet. 2. More problematic is the Dwarf exception handling mechanism requires a language specific "personality" handler. This is supplied by the D runtime library. Trying to trick the C runtime library one…

> RAII requires exceptions to be correct. I'm not exactly sure what you mean here, but all I really want is guaranteed destructors. Can we just have those?

> Can we just have those?

It's a good thought. D as Better C is new for us, and we'll be flexible in making it work better.

Re: D as a Better C

#90

Post by fithisux »

"Exceptions, typeid, static construction/destruction, RAII, and unittests are removed"

Thank you guys

"But it is possible we can find ways to add them back in."

Over my dead body

Post reply on HN