Live data from Hacker News

My Vision of D’s Future

dlang.org

91–100 of 211 posts

Re: My Vision of D’s Future

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

Java can do this via AOT or partially also JIT compilation. For AOT there is this JEP: https://openjdk.java.net/jeps/295 and a different project: the GraalVM

Java could do this always, as it's a compiled language (the important thing here is interactivity vs. compilation, not JVM vs. native).

So I'd say that Java can do "this" since recently (JDK 9 in 2017) via JShell (I wouldn't count BeanShell or Groovy), i.e. it always had the compiler part but added the interpreter.

Although its usage is still quite rare, whereas the blog post would suggest a different pattern.

Re: My Vision of D’s Future

#92
post #26
post #5

Earlier quoted context omitted.

The sad part is, every time I type dlang in google for something, it tries to correct it to golang and that's terrible. duckduckgo doesn't do that.

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

Re: My Vision of D’s Future

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

I also have this problem. I find part of D is easy like Python, but all the template jargon is over my head.

Re: My Vision of D’s Future

#94

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.

... and over the past decade-and-a-bit, C++ has been evolving itself quite nicely (IMHO), so the motivation for moving away from it has decreased. Also, now D probably has to "chase" some C++ developments.

Re: My Vision of D’s Future

#95
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 :-).

Zig is doing this, an interesting feature.

Re: My Vision of D’s Future

#96
post #13

Earlier quoted context omitted.

I find D easier to use than Rust or Go because of familiarity. It is very obviously C and C++ inspired but without all the sharp edges. I also love D's metaprogramming. It feels almost like lisp. Go's lack of generics doesn't allow this and Rust's macros don't feel as comfortable for me. Yes, D is smaller but it's also big enough for me. I don't feel like I'm missing out on much when I'm using D. If I need a library…

Good post. I haven't used D much, but the only way I really see it as "deficient" is its inability to easily create static binaries, like Go. But in a lot of ways that is never a hard requirement (it is nice, though).

You totally could create static libraries or compile stuff statically inside binaries to create a go style standalone executable but you need to recompile Phobos as a static lib for that

Re: My Vision of D’s Future

#97
post #3

As long as we search for stuff on the internet with text terms (i.e. Google ) you've got to enhance the name of the language. If only something boring as DLang, please please do this. I feel bouts of sympathy every time I think of D, and I'm not even a hard core fan or anything. No need to change the logo or anything. Just sneak in something actually searchable ( dlang , or whatever ) in footers and headers of docume…

It's beyond me why most languages fall into this trap: C, C++, C#, D, Go, etc. All hard to search for. Granted some of these predate the internet, but most do not. Almost looks like some kind of secret agreement between language designers.

I'm going to name my language after ' ', ascii 32

Re: My Vision of D’s Future

#98
post #18

Earlier quoted context omitted.

Why can't Rust match that?

Most languages settle down with C interop and don't bother with the added complexity from C++. Rust is one of those, some of the concepts aren't even on the language right now, what would lead to very non-idiomatic imports.

The Rust bindgen tool automatically generates Rust FFI bindings to C and C++ libraries. Mozilla uses bindgen a lot to interoperate between Firefox's C++ and Rust code. IIUC, Rust and C++ code can't seamlessly call each other unchanged, but bindgen adds FFI glue that makes it much easier.

https://github.com/rust-lang/rust-bindgen

Re: My Vision of D’s Future

#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 i; parallel(arr)) i = i * i;

Example was shamelessly lifted from: https://tour.dlang.org/tour/en/multithreading/std-parallelis...

Re: My Vision of D’s Future

#100
post #78

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.

When you believe in systems programming languages with tracing GC support, powerful metaprogramming and generic code capabilities that compiles as fast as Go.

.. and with much better run-time performance than Go.
Post reply on HN