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

My Vision of D’s Future

dlang.org

Post reply on HN
Print view View original

131–140 of 211 posts

Re: My Vision of D’s Future

#131

Post by abaga129 »

anaphor wrote: post #113
abaga129 wrote: post #84

Earlier quoted context omitted.

Having to use .array() on the Result of some functions is the exact same problem I've ran into as well! D is by far my favorite language but there is definitely some room for improvement in terms of documentation on how to use the standard library.

On the other hand, I like the explicitness of it instead of automatically converting to a different type. At least you know exactly what it's doing. The python version of it would be calling `list()` on things all the time, which you might not always want to do.

That's a fair point. I'm not necessarily against having to do it, I just would like there to be a more obvious indication of how to convert the result to an array. It took a lot of searching the first time I came across this.

Perhaps it's just my own incompetence though!

Re: My Vision of D’s Future

#132

Post by abaga129 »

jordigh wrote: post #90
abaga129 wrote: post #84

Earlier quoted context omitted.

Having to use .array() on the Result of some functions is the exact same problem I've ran into as well! D is by far my favorite language but there is definitely some room for improvement in terms of documentation on how to use the standard library.

It's not the best idea to always unconditionally use .array because you might want to preserve the laziness of a Result type. By using .array you're saying you want all of the results into memory right now! Depending on what you're doing, you might not want that.

I actually didn't know this! Very cool. I guess it's similar to calling .ToList() on IEnumerable in C#.

Re: My Vision of D’s Future

#133

Post by ZootAllures91 »

thiago_fm wrote: post #11

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.

Well, for example:

  import std.stdio;

  struct Math(string Op) {
    static auto eval(T, U)(T l, U r) {
      static if (Op == "+")
        return l + r;
      else static if (Op == "-")
        return l - r;
      else static if (Op == "*")
        return l * r;
      else static if (Op == "/")
        return l / r;
    }
  }

  static immutable auto result = Math!("+").eval(1, 2) + Math!("*").eval(3.0, 3.0);

  void main() {
    writeln(result);
  }
You'll never be able to do anything like that in Rust until const generics are not only complete on their own, but also fully compatible with "const fn".

Re: My Vision of D’s Future

#134

Post by 7thaccount »

thiago_fm wrote: post #11

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.

Rust is pretty low level. As a Python programmer I can use D a lot easier (with the exception of templates and all the stuff that assumes you know C++ which I don't) than Rust as I don't have to worry about memory.

Re: My Vision of D’s Future

#135

Post by anaphor »

abaga129 wrote: post #131
anaphor wrote: post #113

Earlier quoted context omitted.

On the other hand, I like the explicitness of it instead of automatically converting to a different type. At least you know exactly what it's doing. The python version of it would be calling `list()` on things all the time, which you might not always want to do.

That's a fair point. I'm not necessarily against having to do it, I just would like there to be a more obvious indication of how to convert the result to an array. It took a lot of searching the first time I came across this. Perhaps it's just my own incompetence though!

It's definitely not your incompetence. I started learning D a few months ago and it didn't click until someone on IRC explained it clearly to me. It's not in the tutorial or anything unless I missed it.

Re: My Vision of D’s Future

#136

Post by giancarlostoro »

WalterBright wrote: post #106
alexashka wrote: post #64

The one comment on the article on the page I think is spot on - I think every programmer language designer underestimates the importance of good IDE support.

> I think every programmer language designer underestimates the importance of good IDE support. Oh, we're well aware of it. It's just that the language design part consumes all our time.

Thankfully we've now got LangServer thanks to Microsoft which helps tremendously! It means any IDE / editor can be useful once at least a single LangServer project is made per language. Code once, use anywhere!

A good IDE used to be my hangup for D but VS Code has a very solid plugin.

Re: My Vision of D’s Future

#137

Post by zucker42 »

paulddraper wrote: post #122
kernyan wrote: 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.

Most JIT runtimes also can't produce a standalone binary

Re: My Vision of D’s Future

#138

Post by btbytes »

atombender wrote: post #104
kernyan wrote: 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's default package manager already allows you to write code like this which 1. runs the code like a script 2. downloads dependencies if they are required.

    #!/usr/bin/env dub
    /+ dub.sdl:
        name "allthepythons"
        dependency "d-glob" version="~>0.3.0"
    +/

    import std.stdio : stdout;
    import glob : glob;
    
    void main () {
        foreach (entry ; glob("/usr/local/bin/python*")) {
            stdout.writefln("%s", entry);
        }
    }

Re: My Vision of D’s Future

#139

Post by k__ »

pornel wrote: post #105
efficax wrote: post #22

Earlier quoted context omitted.

Rust doesn't have classes, for one?

More specifically, Rust doesn't have inheritance of data. It uses composition and can simulate inheritance of interfaces. That suffices for Rust programs, but gets awkward quickly with some classic OOP-heavy design patterns. Despite superficially similar angle bracket syntax, C++ templates and Rust generics are very different and incompatible in all but most trivial cases. D templates can get closer. Rust also lacks…

Seems like Mozilla uses Rust with C++ in Firefox on a daily basis: https://news.ycombinator.com/item?id=21262860

Re: My Vision of D’s Future

#140

Post by paulddraper »

zucker42 wrote: post #137
paulddraper wrote: post #122

Earlier quoted context omitted.

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.

Most JIT runtimes also can't produce a standalone binary

Pretty much all JITs have tools for standalone binaries.

People usually don't do it because JITs are heavy so they'd prefer to share them.

Post reply on HN