D on embedded Linux (ARM) | Hacker News Reader

D on embedded Linux (ARM)

fkromer.gitbooks.io

97 pointspjmlp25 comments

It's always exciting for me to see more D usage. What's nice is that it has both gcc and llvm frontends, with all the optimisations and target architectures that those come with, such as the article's ARM.

I recently worked through Advent of Code in D to get a better feel for the language, and I had a blast. It's a fun language with some very interesting ideas.

http://jordi.inversethought.com/blog/advent-of-d/

I particularly enjoyed concurrency during Day 18, which seemed to really stump those who tried Advent of Code in other languages, whereas D made it very easy.

http://jordi.inversethought.com/blog/advent-of-d/#day18

I wonder if D could ever become mainstream at this point. Back when the language first released as a C++ coder I was very interested in D but the weird not-technically-open-source license and the garbage collector put me off. Now they "fixed" the licensing and I suppose garbage collection is more readily accepted in system programming but it doesn't have the hype and novelty of Go or Rust. I don't know any program I use that's written in D for instance while I do use a few Rust and Go programs daily. I can't shake the feeling that D missed its chance at becoming mainstream.

I just use it without worrying if it's popular or not. It's popular enough to have a good collection of 3rd party libraries and a very good standard library, and a package manager inherited from the popular enough Vibe.d web framework. Vibe.d It's popular enough to be officially part of the GNU compiler collection. It's popular enough for there to have been enough interest to keep pushing for a license change for the reference compiler.

It doesn't have a Rust Evangelism Strike Force, but that doesn't make it any less of a fun language.

It has been proven multiple times, at Xerox PARC, ETHZ, DEC Olivetti, Microsoft that garbage collection systems programming languages are doable.

However technology adoption always needs to fight against non-believers.

Joe Duffy has stated on his Rustconf 2017 presentation [0] that even Midori running on front for their eyes, with some use cases where System C# was even shoulder-with-shoulder with C++ [1], that Windows devteam was not getting it.

Nowadays he is an happy Go coder instead of trying to convince them otherwise.

D has a big problem with their GC implementation, which provides good arguments for the anti-GC crowd in systems programming.

However they have been improving it quite a bit during the latest releases, as well as, making the runtime library more @nogc friendly.

As for reaching mainstream, I share your thoughts. It is not only Rust and Go. There is also Swift, C++17 and the ongoing improvements to make Java and C# more machine friendly (memory management and AOT compilation).

Still, even if just a small group gets to use it, it is already a victory.

Most languages never achieve it.

[0] - https://www.youtube.com/watch?v=CuD7SCqHB7k [1] - http://joeduffyblog.com/2015/12/19/safe-native-code/

> It has been proven multiple times, at Xerox PARC, ETHZ, DEC Olivetti, Microsoft that garbage collection systems programming languages are doable.

It's my understanding that D's garbage collection isn't considered very performant. I know it used to receive a lot of criticism.

Which I happen to address on my comment....

I like the fact that it's a GC language. You can also disable the GC using the @nogc pragma. Efforts have been recently made to make a bigger part of the standard library @nogc compliant.

If I wanted to write a program with @nogc, how much of a QoL hit would I take? Is most of the standard library usable without garbage collection, or is it more hit-or-miss?

I know std.container can function w/o the GC. The rest is probably a hit or miss:

https://forum.dlang.org/post/p6cq7f$2cg$1@digitalmars.com

D is much, much easier to get into than rust though. Rust is in the C++/Scala realm of complexity, while D is as easy as C# or Java.

But D does not have the hype-machine behind it that rust does. Rust also does have advantages, it's a bit more safe by default, and is based around concepts that are very much in-vogue (ADTs and pattern matching). But I don't think rust is nearly as productive.

We'll see how it all shakes out.

I'm really glad you mentioned the concurrency problem from day 18, because this was one of those personal "eureka!" moments I had while learning D. I had no idea that concurrency could be so simple, and this is not even having any special built-in support aside from thread-local data by default. This is all in _user_ code.

By that same token, std.parallelism.parallel was one of those things where I just looked at it and thought "man, you can actually _do_ something like that?"

I really think D, like Go has a better chance of attracting programming languages from higher, not lower level languages.

C++ can't event get the C greybeards to switch over while being a strict superset. On the other hand, Go is being embraced as a python replacement in the backend world

pedant here: C++ is far from a strict superset of C, with many syntactic changes over the years.

Yes, at this point they're disjoint https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

C++ is actually missing some of the nicer stuff from the last few ANSI-C standards. Struct initializers especially.

That is what constructors are for.

In any case, they might make it into C++20.

http://en.cppreference.com/w/cpp/language/aggregate_initiali...

Rust is hard. But languages live and die by mindshare. Can D run on a 20k microcontroller?

Maybe, if stripping the runtime and making use of the betterC compiler mode.

In any case, with only 20 KB available, the only sane option is Assembly, as every byte counts.

Any kind of high level programming just means using a crippled language, trying to match Assembly, while wasting more space.

Well, Rust can. I‘ve spent the last week to see if its true. But I wished it was easier.

With 20KB available it hardly is Rust anymore.

Just like C and Pascal compilers, the result with hacks to make the generated code fit and beat manually written Assembly is not worth it.

It would also be possible to do it with D, using betterC mode and no runtime, assuming a backed for then target architecture would be available.

To clarify, I was talking about RAM, not flash. Binary size is still a problem, thats true. And yes of course you need to go the no-std route, but it works.

What about Forth ?

Yeah, sweet memories of FORTH, but 20 KB is not something one wants to "waste" bytes and you would need a few of them for the dictionary and basic words.

> C++ can't event get the C greybeards to switch over while being a strict superset

1. C++ is not a superset of C

2. Not all C loyalists are greybeards, or even old.

How often do you use the restrict keyword, seriously?

Reply on news.ycombinator.com