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

101–110 of 193 posts

Re: D as a Better C

#101

Post by zombinedev »

ziotom78 wrote: post #46
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…

I am in a similar situation, as I develop a lot of scientific code. I've tested several solutions, and so far the most viable for me (though far from perfect) is Python+NumPy+Fortran, the latter exposed to Python using f2py (much easier than binding C/C++ to Python). Not sure if this might be a good solution for you, it depends whether the bottleneck in your code is in I/O or in raw calculations (in the former case y…

D has quite good multi-dimensional array support, though probably not as flexible as Python. One of the best libraries in this area is ndslice (part of mir-algorithm) - http://docs.algorithm.dlang.io/latest/index.html. See the "Image Processing" example to get a sense of API - http://docs.algorithm.dlang.io/latest/mir_ndslice.html. mir-algorithm is the base for the high-performance glas implementation written in pure D that outperforms libraries with hand-written assembly like OpenBLAS in single-threaded mode (multi-threaded is not yet ready). See http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/.... (Note that this blog post is bit outdated - since then the author rewrote large parts of the library, IIRC.)

Re: D as a Better C

#102

Post by e12e »

dom96 wrote: post #52
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…

(Disclaimer: one of the Nim core devs here) Happy to see you paint Nim in a (sort of) positive light, I hope I can help with this one negative. > I liked Nim better in almost every way but one: the compiler was fickle and would just fail silently sometimes. Can you give some examples and elaborate on what you mean by "fail silently"? Did you at least get a segfault?

Since it's already brought up in this thread, I recently had (another) look at nim and was a little disappointed too.

It's been a while, but as I recall, on Windows - it was difficult to find a supported way to output Unicode on the console in a sane, portable way (write utf8 nim source code, get wide strings in Windows console and utf8 under eg Linux) - and I think I also had some problems getting off the ground with statically linking sdl2 (again on Windows).

The build/package/config system appear to in a bit of flux?

[ED: and I think there were old open issues and forum posts for both problems, hence no new bug reports...]

Re: D as a Better C

#103

Post by zombinedev »

srcmap wrote: post #81

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…

D provides the same low-level access as C. Heck, in D you can even use inline assembly, so there are really no barriers to what you can achieve. MMaping files and casting their contents to structures is often used technique. The GC only one of the many ways of getting memory in D. You'll just have to manage the other ways yourself like in C or C++ ;)

Re: D as a Better C

#104

Post by pjmlp »

Keyframe wrote: post #100
pjmlp wrote: post #24

Earlier quoted context omitted.

You can easily get best of both worlds with Lisp derived languages.

I like Lisp, though Scheme in particular. However, I have no idea where I would turn to in order to write an application with GUI that needs to be cross-platform and, possibly, derive a mobile version for iOS and Android from the same codebase.

To mocl

https://wukix.com/mocl

Re: D as a Better C

#105

Post by theprotocol »

steveklabnik wrote: post #84
christophilus wrote: post #76

Earlier quoted context omitted.

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 :)

Could you point to any materials (e.g. blog post, roadmap document...) that deal with this? Thanks.

Re: D as a Better C

#106

Post by vvanders »

WalterBright wrote: post #47
Ace17 wrote: post #35

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

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…

Rust uses RAII all over the place and doesn't have exceptions :).

Re: D as a Better C

#107

Post by millstone »

WalterBright wrote: post #85
millstone wrote: post #66

Earlier quoted context omitted.

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.

Gotcha. C++ has the same problem when its exceptions are thrown through C or -fno-exceptions C++ frames.

If that's the only hold-up, IMO the way to go is to abort at the boundary, when an exception would propagate into frames without unwind tables. RAII is too valuable to do without!

Re: D as a Better C

#108

Post by gmfawcett »

skymuse wrote: post #31
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;

You can also emit the type during compilation, rather than at runtime:

pragma(msg, "var has type: ", typeof(var));

Re: D as a Better C

#109

Post by pjmlp »

rifung wrote: post #99
steinuil wrote: post #80

Earlier quoted context omitted.

Common Lisp has some very fast implementations (I think SBCL is the fastest) and it was designed to be a systems language. It can be optimized to be as fast as C.

> It can be optimized to be as fast as C Sorry if dumb question but how is this possible when it's garbage collected? Now I really feel like I need to learn a Lisp though.. Is there a certain Lisp you would recommend that's practical enough I'd use it for projects? Racket?

You can start by reading about Genera and Interlisp-D

https://en.wikipedia.org/wiki/Genera_(operating_system)

https://www.ics.uci.edu/~andre/ics228s2006/teitelmanmasinter...

http://www.softwarepreservation.org/projects/LISP

Just check the hardware capabilities of systems having Lisp 1.5 support, several years before C was created.

Lisp is not only manipulating lists, it grew up to natively support all relevant data structures, including primitives to handle systems programming tasks.

Regarding GC and systems programming, there are plenty of GC enabled systems programming languages, the main point is that they offer features to control the GC and also do stack and GC free allocation if required.

Some examples would be Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Oberon-07, Active Oberon, Component Pascal, Sing#, System C#, D

Re: D as a Better C

#110

Post by steveklabnik »

theprotocol wrote: post #105
steveklabnik wrote: post #84

Earlier quoted context omitted.

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

Could you point to any materials (e.g. blog post, roadmap document...) that deal with this? Thanks.

https://blog.rust-lang.org/2017/07/05/Rust-Roadmap-Update.ht... is our "the year is half over" update, and has a link to the overall goals right at the top.
Post reply on HN