Does anyone know what the package management story is like for D? And also what is the D ecosystem like for embedded systems?
It is called dub.
Regarding embedded, there were some progress lately, but still needs some improvements.
D as a Better C
21–30 of 193 posts
Re: D as a Better C
#22D is betting hard on memory safety, and apparently system programming honestly i think, had they gone in the direction of D as a better Python, and application development, they would have made bigger wins (in terms of popularity) ... better tooling, better ide, refactoring, better GC, better libraries ... better faster programs
D's objective is/was not to be popular but rather to be exactly what it is: a better low-level language. From what I can gather, it succeeded pretty well at that, lacking maybe some hype. The recent open-sourcing of the toolchain might help though.
> D's objective is/was not to be popular but rather to be exactly what it is: a better low-level language.
I don't believe that one second, every language strives to be popular and reach large adoption, since more developers == more maintainers == bigger ecosystem == more reach into enterprise.
Re: D as a Better C
#23I tinkered with D a bit (along with Nim, Dart, and C as a comparison) while writing a Clojure interpreter. D seems to be a nice language, but I found the editor integration wasn't the best. I also found it annoying that the docs used `auto` all the time, so you could never figure out the right type annotations for their APIs (e.g. I want to call the foo API and return its value from my method, but the docs all use `a…
>Nim, Dart, and C as a comparison) Could I ask about your thoughts regarding Go (which has much less syntax and fewer features than all of the above). Have you looked into it?
Yeah. It should have been in that list, actually. I wanted to like Go. It seems simple (which is what I like so much about Clojure), but honestly, I found it to be frustrating for all the standard reasons the Go team is tired of hearing (e.g. no generics, error handling littering my code and obscuring intent, etc).
In fact, I think Go doesn't quite deserve the reputation it has as being a simple language. It's a familiar language, and it's a bare-bones language, but that's not the same thing as being simple.
One last thing that was interesting: I got more null pointer runtime exceptions in Go than I expected (vs none in Nim, for example). Granted, I'm a Go n00b, but I'm also a Nim and Dart n00b, and didn't have nearly as much trouble with those two languages (aside from the aforementioned compiler bugs).
I really wish modern statically typed languages would rid us of null pointer errors once and for all. This is totally possible with Option types, but seems to rarely be done. I wonder why?
Re: D as a Better C
#24Earlier quoted context omitted.
I really really don't been to pile on Python... but every time I've had to interact with it I've been shocked at how slow it is compared with C or C++. I tend to write scientific code to process datasets in the range on 10Gb, for simple operations Python code can take hours as opposed to just taking minutes or seconds in C. I'm sure it's possible to write more highly optimized code in Python, but it never seems to be…
Python is a high-level interpreted language, and C/C++ are low-level (even compared to other) compiled languages. While you might be able to optimize your Python code to run faster than it does now, it's never going to match the performance of C/C++, nor is it intended to. Go will be a significant speedup over Python, but likely won't quite match the speed of C/C++ for most tasks. Then again, the ease of development…
You can easily get best of both worlds with Lisp derived languages.
Re: D as a Better C
#25Earlier quoted context omitted.
D's objective is/was not to be popular but rather to be exactly what it is: a better low-level language. From what I can gather, it succeeded pretty well at that, lacking maybe some hype. The recent open-sourcing of the toolchain might help though.
> D's objective is/was not to be popular but rather to be exactly what it is: a better low-level language. I don't believe that one second, every language strives to be popular and reach large adoption, since more developers == more maintainers == bigger ecosystem == more reach into enterprise.
I would hold up Haskell as another counter example to your assertion.
Re: D as a Better C
#26D is betting hard on memory safety, and apparently system programming honestly i think, had they gone in the direction of D as a better Python, and application development, they would have made bigger wins (in terms of popularity) ... better tooling, better ide, refactoring, better GC, better libraries ... better faster programs
Ironically, there are very few choices for programmers who want to write memory safe, high performance systems code. There's plenty of choice at the Python level.
BetterC is a way for C programmers to gradually move to memory safety without disrupting their valuable, tested investment in working code.
Re: D as a Better C
#27I tinkered with D a bit (along with Nim, Dart, and C as a comparison) while writing a Clojure interpreter. D seems to be a nice language, but I found the editor integration wasn't the best. I also found it annoying that the docs used `auto` all the time, so you could never figure out the right type annotations for their APIs (e.g. I want to call the foo API and return its value from my method, but the docs all use `a…
The D standard library is generally designed to generic code: you often aren't supposed to see the type returned by a function.
Also, you can use auto too + Template constraints would help you here.
Re: D as a Better C
#28Earlier quoted context omitted.
The better Python market isn't an easy one to crack because its a bit crowded. Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Python itself is improving rapidly, for example with the addition of Type Hints. Its pretty difficult to be a better Python in 2017. The better C market, on the other hand, hasn't seen any real…
According to their respective Wikipedia articles, D is 8 years older than Go. Given that you're saying that Go had a lot of success breaking into the Python market, why couldn't D have instead if they had put their efforts there from the beginning?
I suspect a large part of go's initial success are the names attached to it, both Google and the team have great reputations. Go's continued success is a credit to the language, but maybe D has had some discoverability issues?
Re: D as a Better C
#29Earlier quoted context omitted.
D's objective is/was not to be popular but rather to be exactly what it is: a better low-level language. From what I can gather, it succeeded pretty well at that, lacking maybe some hype. The recent open-sourcing of the toolchain might help though.
> D's objective is/was not to be popular but rather to be exactly what it is: a better low-level language. I don't believe that one second, every language strives to be popular and reach large adoption, since more developers == more maintainers == bigger ecosystem == more reach into enterprise.
That's not so simple, because large adoption at a too early stage causes the language definition to freeze before it reaches maturity.
Simon Peyton-Jones from the Haskell community explaining exactly that: "What happens if [a language] become successful too quickly? You can't change anything!" https://www.youtube.com/watch?v=re96UgMk6GQ&t=1395
Re: D as a Better C
#30int main(char** argv, int argc) { Really? :-)
How embarrassing :-)
But it doesn't affetc the opertaion of the prorgam (I did test it).
Edit: fixed it