101–110 of 211 posts
Earlier quoted context omitted.
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).
Why can't D create static binaries? I've never heard that before.
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 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.
The similarities are more surface deep once you start learning more about the different features and tools D offers.
>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…
go run main.go
go run ./cmd/server
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() {
println("Hello world!")
}
Earlier quoted context omitted.
Why can't Rust match that?
Rust doesn't have classes, for one?
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 many C++-isms: there are no copy/move constructors, no custom code can run on assignment, operator overloading is more conservative, there's no life before main(). Error handling, iterators, and strings are done differently.
Even if C++ could magically work in Rust, it'd be weird. OTOH D feels much like a rewrite of C++.
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.
Oh, we're well aware of it. It's just that the language design part consumes all our time.
>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…
I love D and one space I want to see more of is DMD on SBC's and moreso than that D running on WebAssembly, Go and Rust do it. I consider Rust and Go the main competitors to D, not sure if others would agree, but that's just my view. Other than that it's a great language.
Earlier quoted context omitted.
Why can't D create static binaries? I've never heard that before.
Sorry -- it can, but in much the same way GCC does. You need to manage all your deps. With go it just happens, a huge time saver.
But I appreciate how that's not necessary and I can use only system-installed libs with Meson and pkg-config :P
Earlier quoted context omitted.
Yes, there's an extra barrier with D because of type checking, but in exchange, you get compile-time checks. I actually kind of like those template errors because they tell you what kind of Python-like compile-time duck-typing D is trying to use! Oh, and you can also use type deductions for function declarations! Just make it a template and let D figure out for you what type you want, or use typeof to record the type…
That second feature sounds really neat. I'd always wished Go had implemented something like this, even if just for numeric types.