Live data from Hacker News

My Vision of D’s Future

dlang.org

141–150 of 211 posts

Re: My Vision of D’s Future

#141

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'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); } }

Dub's documentation should use some love...

Re: My Vision of D’s Future

#142
post #37

What about -betterC? I always thought this was a nice "pivot" for D. It would be great to have more support for this direction. You can't avoid malloc there, but maybe some instrumenting for leak detection or some libc replacements that exploit or are exploited by the language. Other than that, I'm okay with anything that was already in Eiffel or Modula-3…

BetterC was created at first to make it easier to port D compiler from C to D. Then people realized that it might be interesting to have D without GC and without runtime, because it makes it trivial to port to other platforms such as embedded, mobile or WASM. The problem is, betterC is kind of in that awkward spot. It's not comparable to the "real" D, and if you can live with betterC, you might as well just use C and…

> if you can live with betterC, you might as well just use C and enjoy the wide C ecosystem.

If you can be bothered to use betterC then that's probably not true. To be argumentative, C is fucking horrible. BetterC still gives you a decent chunk of D's features - templates alone make it worth the switch. No more macro spam for example.

Can you imagine how much boilerplate you'd have to write to mimic this: https://d.godbolt.org/z/3XNBFW

Re: My Vision of D’s Future

#143
post #89
post #6

D needs to up its game with the Techempower benchmarks IMHO. Vibe.d has been completely left behind by the usual Rust/Go/Java suspects. I'm very confident that it is capable, but that isn't particularly obvious atm.

Wow, Rust is a beast.

I think this is more of a measurement of how much effort people have spent implementing the benchmark, e.g. Based on a cursory look six months, a few of the rust ones seem to have been implemented with some parts from scratch rather than just hammering it together like the D implementation.

There was also one where dmd was faster than ldc, so something must be up somewhere

Re: My Vision of D’s Future

#145
post #70
post #67

Earlier quoted context omitted.

But as a language doesn't betterC provides lots more useful features than C (the module system, meta-programming (imagine C with generics), scope() and many other useful things) that make it really a better language than C while still keeping C interop. I agree that it is in an awkward spot though -- and would have benefited from being it's own separate programming language. It would have been a killer feature if it…

It would have been a killer feature if in betterC mode it could compile standard C programs and be a drop-in replacement for GCC/Clang :-).

You might find Atila's project dpp interesting: https://github.com/atilaneves/dpp

Re: My Vision of D’s Future

#146

I have to say, I like what I read there. I'm glad they're working more on c++ interoperability. I've ported some c++ code to D before, it wasn't not too bad, it wasn't a lot of code, but it would be great to be able to work directly with c++ libraries in D similarly to C libraries. It always makes me sad D hasn't picked up more. Usually comments I see about D seem pretty ambivalent to dismissive. It's a great languag…

The main reason that D hasn't been picked up by anyone is mostly because it is an evolution of C++, not a revolution. Discarding an entire ecosystem for an evolution is not going to happen. Rust took a very different approach and just threw everything away. D looks and feels too much like C++, I would rather have hoped that effort would have been spent on making C++ better.

I have programmed in both for years (commercially) and don't understand the comments about D being like C++. This is a night and day difference to me.

Re: My Vision of D’s Future

#147
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…

> Most of the standard library function calls return some opaque Result type

This is by design, e.g. map could not be lazy if it returned an array.

> Oh, and I don't even know if it's possible to pass such Result to a function because you have to use auto to declare it.

templates, void use(T)(T x) [auto ref if you feel fancy]

Re: My Vision of D’s Future

#148
post #25

Earlier quoted context omitted.

I don't think anybody really cares about the Techempower benchmarks. Else we'd all be using Vert.x or so. The most popular frameworks having the 90% of deployments, are at the middle to bottom of the Techempower benchmarks.

We actually do care about those benchmarks. At a certain scale it matters how many servers you need to run a website with millions of visitors. 90% of deployments do not have this problem, yet saying nobody cares is a bit silly.

At that scale do you use a stock framework though?

An advantage of D in that situation is how easy it is to change the internals of an API without those changes propagating to the surface, both by design (e.g. UFCS, no brackets) and how that design is used (e.g. Templates)

Re: My Vision of D’s Future

#149

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…

Assuming I formatted it right, I made your example shorter

  import std;

  template Math(char Op) {
     auto eval(T, U)(T l, U r) {
        static foreach(x; "+-*/") {            
         if (Op == x)
          mixin("return l ", x, " r;");        
        }        
    }
  }

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

  void main() {
    writeln(result);
  }

Re: My Vision of D’s Future

#150
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.

Do either Visual D or Code-D work with Linux or WSL? It would be really nice to have the GUI for debugging linux code. Some libraries are just much easier to get set up in linux.
Post reply on HN