Live data from Hacker News

My Vision of D’s Future

dlang.org

121–130 of 211 posts

Re: My Vision of D’s Future

#121
post #30

>I think we need a ridiculously fast interpreter so that we can skip machine code generation and linking. To me, this should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. This would also enable a REPL. I am most excited about this, where a language supports two modes 1) interpreter for devel…

I'm a fan of Go's "go run". For example, you can do: go run main.go or: go run ./cmd/server When invoked this way, Go compiles your code behind the scenes, but you don't have to create a binary. This means Go lends itself pretty well to ad-hoc scripting or writing small script-like tools. Unfortunately, Go doesn't support shebang lines, but with gorun [1] you can: #!/usr/bin/env gorun package main func main() { print…

D already works like this.

Scala (Ammonite) works like this.

The author isn't complaining about keystrokes; he wants the compile + run process to be faster. Using an interpreter instead of a compiler would make it faster.

Re: My Vision of D’s Future

#122
post #30

>I think we need a ridiculously fast interpreter so that we can skip machine code generation and linking. To me, this should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. This would also enable a REPL. I am most excited about this, where a language supports two modes 1) interpreter for devel…

JIT runtimes try to give you both.

It starts interpreted, but if you run for very long, it runs compiled.

But that costs memory and startup time.

Re: My Vision of D’s Future

#123

Can somebody enlighten me, why use D when there is Rust/Go? I think on almost all cases, and also having a bigger community, it is a win for Rust/Go.

D is easier to use than rust and way more capable than go.

Re: My Vision of D’s Future

#124
post #47

Earlier quoted context omitted.

I find that D is about as easy as Python to get into. Being able to use rdmd as a shebang makes D almost feel like as scripting language. A lot of Python was also pretty easy for me to directly translate into D. Here is an example: http://inversethought.com/hg/medcouple/file/tip/medcouple.py... http://inversethought.com/hg/medcouple/file/tip/medcouple.d#...

While I enjoy using D, I find it hard to use at times. Especially if someone isn't a C++ veteran, as soon as heavy template usage comes into play I get confused, and error messages are useless because it's several screens of errors with multiple isX() && !isY() && isZ() conditions for types. Most of the standard library function calls return some opaque Result type which isn't obvious how to progress from. Only after…

Let me give you a little guidance on this (if you happen to still be using D). Most functions in std.algorithm (and many more throughout the rest of the standard library) return "ranges", which is like a begin iterator and an end iterator zipped up into one data structure. There is a "range hierarchy" that mirrors the C++ iterator hierarchy:

Input/Output Range > Forward Range > Bidirectional Range > Random Access Range

Input ranges provide the following API:

    bool empty()
    T front()
    void popFront()
Forward ranges provide the same API, and also add a "save" function that creates a copy of the range's current state.

Bidirectional ranges add "back" and "popBack" functions, which don't really need any explanation.

Random access ranges additionally add a "length" function and constant-time array-like indexing.

In addition to most functions in std.algorithm _returning_ ranges, most of them also _accept_ ranges. Therefore, you can freely pass the result of any function in std.algorithm into another function that takes a range, and it should all just work. It's pretty much the same deal as in Rust/Java/Swift/etc. with their various iterator protocols, although the API for ranges in D is more influenced by C++.

For example, the first Project Euler problem, using a range-based approach:

    import std.algorithm;
    import std.range;
    import std.stdio;

    void main()
    {
        //List all the natural numbers below 1000 that are multiples of 3 or 5
        auto natsBelow1000 = iota(1000); //iota returns a range that lazily computes the numbers from 0-999
        auto multiplesOf3Or5 = natsBelow1000.filter!(n => n % 3 == 0 || n % 5 == 0); //filter accepts a range as an argument, which it lazily filters according to the given predicate
        auto sum = multiplesOf3Or5.sum(); //Sum accepts a range of "summable" items and computes the... sum
        writeln(sum); //Prints 233168
    }
A D programmer wouldn't generally write things this way, preferring to make a more idiomatic "range chain" like you'd see with Java's streams or Rust's iterators, but you get the idea.

As you might have guessed, arrays are also ranges - random access ranges - which is why they're so easy to use.

I would highly recommend against putting `.array` everywhere in your code, as it will force the range you pass to it to be eagerly evaluated and allocate more memory from the GC. It's much better to take some initial data store, like an array, do all your filtering and mapping, etc. on it, and when you're done, _then_ turn it back into an array with a call to `.array`. That way you'll get all the lazy iteration and low memory footprint of ranges, and then at the end you have a nicely allocated array of data with the result that is easy to work with.

Honestly, though, in most of my code I usually just pass around ranges as they're very good for creating interlocking adapters over different backing stores. One really great article on advanced usage of ranges is H. S. Teoh's article on Component Programming with Ranges: https://wiki.dlang.org/Component_programming_with_ranges

A couple great resources on ranges in D:

http://www.informit.com/articles/printerfriendly/1407357

https://tour.dlang.org/tour/en/basics/ranges

http://ddili.org/ders/d.en/ranges.html

http://dconf.org/2015/talks/davis.html

Re: My Vision of D’s Future

#125

Can somebody enlighten me, why use D when there is Rust/Go? I think on almost all cases, and also having a bigger community, it is a win for Rust/Go.

It's easier and more productive than Rust and has generics, templates, better C interop than Go. Also the GC can be disabled or worked around.

Re: My Vision of D’s Future

#126
post #92
post #26

Earlier quoted context omitted.

> every time I type dlang in google for something, it tries to correct it to golang and that's terrible Doesn't do it at all to me...

1. https://i.imgur.com/CzGesdb.png 2. https://i.imgur.com/hlGGwWO.png 3. ...

I see. I can get some of those too.

Thought you meant the "Showing results for xxx / Search instead for yyy" correction, which switches your (unpopular) yyy query under you.

The suggestions are annoying, but can easily ignore and insist on my search term.

Re: My Vision of D’s Future

#127
post #33

I wish standardizing documentation tooling (everyone uses a different tool today and ddoc by default has _no_ styling, no navigation, no nothing, so usually nobody writes docs for their code unless it's a big project like vibe.d) and IDE support was on this list (vscode centric tools exist and mostly work, but it's still fairly hit and miss) .. D's tooling has languished for a long time even if it is a great language…

Visual D with Visual Studio is the gold standard, with full debugging, autocomplete, and static analysis support.

Code-D with VS Code is also great, and it has fairly recently gotten funding from the D Language Foundation for further development.

There's also DCD, D-Scanner and dfmt which can be used with a lot of different editors.

Re: My Vision of D’s Future

#129

Earlier quoted context omitted.

I'm a fan of Go's "go run". For example, you can do: go run main.go or: go run ./cmd/server When invoked this way, Go compiles your code behind the scenes, but you don't have to create a binary. This means Go lends itself pretty well to ad-hoc scripting or writing small script-like tools. Unfortunately, Go doesn't support shebang lines, but with gorun [1] you can: #!/usr/bin/env gorun package main func main() { print…

D already works like this. Scala (Ammonite) works like this. The author isn't complaining about keystrokes; he wants the compile + run process to be faster. Using an interpreter instead of a compiler would make it faster.

Java has the same now (since Java 9 I think).

Re: My Vision of D’s Future

#130
post #99
post #24

> We’re mostly there—using the actor model eliminates a lot of problems that would otherwise naturally occur. So D comes with an actor system baked in at the language level? I like that sort of thing after using Erlang and using some half baked libraries in other languages. I’m curious how good it is...

D comes with a lot of "casual parallelism" baked in at the language level, and in its standard libraries. Actors are just one feature among many. You -can- explicitly manage threads and processes like in other languages, but much of the time there is a more lightweight, expressive construct available. For instance, you can turn this loop: foreach(ref i; arr) i = i * i; Into a parallelized loop by simply: foreach(ref…

Much like immutability, I don’t generally find it compelling when a language offers such a critical feature as just one among many. I prefer my languages to be opinionated.

I’m curious how the actor model works on a large system with lots of 3rd party libraries (or even different development teams) when you can’t guarantee that everyone is using it.

Post reply on HN