"Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun"
https://kevinlynagh.com/rust-zig/

D is not mentioned, but the article focuses on issues of conditional compilation and compile-time execution, so I thought the D people will find it interesting.

On Tuesday, 9 March 2021 at 16:48:28 UTC, Mark wrote:
> "Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun"
> https://kevinlynagh.com/rust-zig/
>
> D is not mentioned, but the article focuses on issues of conditional compilation and compile-time execution, so I thought the D people will find it interesting.

Interesting article and it reaffirms what I originally observed with Rust and decided to look elsewhere. Rust for embedded systems is just too cumbersome due to the nature of embedded programming in my opinion and it gets quickly ugly when you step outside the normal application programming comfort zone.

In this particular example, a keyboard controller, is a very simple case of embedded system and despite of that Rust just makes it difficult. Zig as handles that much easier and you can get from A to B without splitting any hairs.

BetterC is a little bit what Zig offers and I would assume that BetterC would be able to handle the task in a similar fashion.

On Tue, Mar 09, 2021 at 04:48:28PM +0000, Mark via Digitalmars-d wrote:
> "Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery,
> and fun"
> https://kevinlynagh.com/rust-zig/
> 
> D is not mentioned, but the article focuses on issues of conditional compilation and compile-time execution, so I thought the D people will find it interesting.

Favorite quotes from the article:

> Despite all this, I still don’t feel comfortable with Rust. It feels fractally complex — seemingly every time I use Rust on a new project, I run into some issue that forces me to confront a new corner of the language/ecosystem.

> Rust has many language features and they’re all largely disjoint from each other, so knowing some doesn’t help me guess the others.

These sound alarming to me, as someone who does not know Rust. Maybe I'm reading too much into it, but it does make me hesitant to try out Rust.

While D is far from perfect, I think it does a lot better in the department of guessability. I've found IME D generally does what I thought it would do, except for the occasional hiccups, bugs, or unexpected corner cases.

Also, IMO D does much better in avoiding fractal complexity -- the core language features generally integrate well with each other, and things generally work without too much nitpicking.  Some of the newer features, however, feel like they're less integrated, and more edging towards fractal complexity territory.


> I was tempted to conclude that, well, all this complexity must be inherent. Perhaps it’s just hard to do compile-time configuration and to iterate over distinct types efficiently in a safe, compiled language?

This was also how I felt in C/C++ before I found D. :-D  I'd say that 70-80% of the time I spent writing C++ is spent wrestling with the complexity of the language and peripheral things like memory management concerns.  It conditioned me to accept that programming is inherently complex, programming languages are consequently inherently complex, and therefore the act of programming must necessarily also be complex.

Then I found D.

Suddenly, many things that were complex in the past are now simpler, sometimes by a lot. I found my mental resources freed up to focus on the problem domain rather than wrestling with the language.  D hits many of the points of friction with other languages IME:

- The tedium of memory management in C/C++: thanks to the GC, my APIs
  are liberated from memory-management clutter, and my brain is freed
  from the constant drone of memory-related concerns to actually make
  progress in the problem domain. (And once in a while when the GC isn't
  good enough, D is flexible enough to allow me to rewrite select parts
  of the code with manually-managed memory -- without having to
  re-architect the entire program from scratch.)

- Boilerplate in Java: when writing Java, I find myself fighting with
  the language more often than actually making progress with the problem
  domain.  A lot of this has to do with metaprogramming features, that
  let me factor away the endless stacks of boilerplate that I'm forced
  to write in Java.

- Too many (nested) loops: lately I've also been enjoying writing
  functional-style code with UFCS -- it's been a big time-saver. Instead
  of writing yet another loop, or worse, N-level-nested loops to express
  some complex data manipulation, a UFCS one-liner neatly encapsulates
  all of that complexity into a form not only fast to write, but also
  easy to read and easy to rearrange, extend, and refactor.

- Single paradigm: languages like Java (or Haskell) force you to
  shoehorn every problem into an OO paradigm (resp. functional
  paradigm). Sometimes, some code is simply better to write in a
  different paradigm, but in these languages you're straitjacketed and
  have no choice, so you end up fighting the language more than making
  progress in the problem domain.  D being multiparadigm is a big boon
  in this respect.

D certainly isn't perfect -- it has its own share of dark corners, WATs, and poorly-interacting corner cases.  But it's a lot better than the other alternatives I've tried so far.


T

-- 
My program has no bugs! Only unintentional features...

On Tuesday, 9 March 2021 at 20:56:12 UTC, H. S. Teoh wrote:
> On Tue, Mar 09, 2021 at 04:48:28PM

💡

Great summary! I don't understand why D isn't used more. Maybe it's *too* flexible for some people? 🤔

On Tuesday, 9 March 2021 at 21:06:46 UTC, Imperatorn wrote:
> Great summary! I don't understand why D isn't used more.

D is my personal language of choice, but it is no mystery to me why it's been so slow to catch on. People always complain about the same (mostly valid) things when asked why they aren't using D (ascending order of importance):

4) Various out-dated criticisms like "the D compiler isn't open source": These complaints are invalid; catching people up on the history of the D project is all that is necessary to deal with them.

3) Small ecosystem: This is valid, but somewhat unfair given that D's lack of popularity is what keeps the ecosystem small. This concern is also mitigated, but not eliminated, by D's excellent interop with C (also Objective-C, Python, and maybe Java?). Getting C++ interop working more fully would help a lot, too, but that's a *very* hard problem.

2) Unsatisfying heap memory management options: D offers an easy to use but inefficient GC, and C-style unsafe manual memory management.

However, what many of the people who would even *consider* switching to D really want is reference counting and borrowing (like C++, Rust, Swift, etc.), with as much compiler automation, optimization, and verification as possible. The D project has been pursuing this goal for years through improved RAII, @nogc, scope, DIP 1000, @live, etc. But, as of today, this subsystem just isn't good enough to replace the GC.

No matter how much anyone on the forums claims that the current heap memory management story is good enough, it won't change the fact that many people who really do find D otherwise attractive are turned away by this limitation. Most of the people who only want GC are off using C#/Kotlin/Java/etc, and are satisfied with them.

1) Buggy/incomplete/absent tooling: This is the big one. I frequently encounter serious compiler bugs, the GDB debugger crashes or fails to properly inspect and step through my programs more often than not, and the D plugin for my IDE draws red squiggles and yellow highlighting all over my correct, valid, working code.

I'm sure my experience in this regard is worse than most, since I make heavy use of various unpopular, incomplete, and new features. But, some of the problems I find and report are in really basic things, too.

All of the above issues have improved a lot in the years that I have been using D, and I think these improvements are reflected in D's increasing adoption. I am very thankful for the hard work of all those people and institutions who have contributed to D's increasing quality. But, there is still a *long* way to go to catch up to the polished "it just works" experience of something like Java.

> Maybe it's *too* flexible for some people? 🤔

There are some people who aren't interested in a complex, multi-paradigm language like D. There are many others who *are* interested, but they're stuck with C++ or have switched to Rust because of the issues with D that I listed above.

On Tuesday, 9 March 2021 at 21:06:46 UTC, Imperatorn wrote:
> On Tuesday, 9 March 2021 at 20:56:12 UTC, H. S. Teoh wrote:
>> On Tue, Mar 09, 2021 at 04:48:28PM
>
> 💡
>
> Great summary! I don't understand why D isn't used more. Maybe it's *too* flexible for some people? 🤔

I don't have any hard data to back this up, but people just haven't really heard of D. Even on hackernews most people aren't particularly familiar with the language, and they're the kind of people who go in for that kind of stuff

On Wednesday, 10 March 2021 at 00:14:18 UTC, tsbockman wrote:
> 3) Small ecosystem
> ...
> However, what many of the people who would even *consider* switching to D really want is reference counting and borrowing

And instead people see a bunch of different, incompatible memory management libraries for things like allocators, non-GC containers, and smart pointers, all of which are in varying states of completeness and buginess, and most of which aren't "standard" to use which makes it off-putting to spend any time at all with them.

Not to mention that just in general, D libraries are mostly hit or miss in terms of quality and whether they even function properly at all, or are supported for more than a week after they're released.

So then you look for a C# or a Java or so on version of what you want, and you'll usually find a well-document, actively-developed/well-tested featureful alternative that has some expectation of doing what you want without too much pain.

For example, 3 or so years ago me and a mentor wanted to write something that needed a database, and I thought it'd be a good time to introduce him to D. So after looking over and trying several database connectors on dub to varying levels of success (one couldn't handle SQL Server's nvarchar type; one couldn't connect for unknown reasons; one required external binaries we had trouble finding pre-compiled versions of and didn't want to spend time compiling it ourself, etc.).

So in the end, we decided to go with Entity Framework, where everything basically just worked and it could even reverse-engineer our database structure into a EF model. Not to say EF doesn't have its warts, but we were up and going within a fraction of the time spent just finding something in D that could actually function at all.

Meanwhile I had a sneaking suspicion that even if we got one of these libraries to work, there'd be some show-stopper bug that we'd run into even in our very simple use case.

Not to mention the rich resources and documentation on the internet for EF, while for a dub library the best you usually get is the README, and if you're lucky, some example files, or depressingly, vice-versa.

And I feel this is the point I often reach where I think: Is D really worth it for this project? Is D's productivity (as a language) going to be able to offset the un-productivity of its ecosystem that I shouldn't just go with C# + some mature library + all the other bells and whistles I need (docs, examples, tutorials, etc.)?

I fear this is not uncommon, but I don't think there's any way to really measure this as a metric.

However, ecosystem aside we still used D for some mild data processing and generation, which D is really enjoyable to make use of.

That being said though, that was also a few years back, so I imagine it's somewhat better now, and there's a project I've been wanting to try to make so I might see for myself soon how things have improved.

> Buggy/incomplete/absent tooling

Slowly but surely. I'm quite happy with code-d now that it doesn't crash every time I make a new line, and that autocomplete doesn't suddenly stop working.

But the squiggles, oh dear me the squiggles.

Debugging is still annoying though, as you said.

I know I'm always quite negative about D in general, but that's due to a desire of wanting it to grow and improve, rather than malice.

On Tuesday, 9 March 2021 at 21:06:46 UTC, Imperatorn wrote:
> On Tuesday, 9 March 2021 at 20:56:12 UTC, H. S. Teoh wrote:
>> On Tue, Mar 09, 2021 at 04:48:28PM
>
> 💡
>
> Great summary! I don't understand why D isn't used more. Maybe it's *too* flexible for some people? 🤔

I think the biggest reasons are bugginess and instability. Those are my reasons for wanting to get out of D, and also feature bloat. I want a simpler language, but am not seeing good options...

Speaking of bugginess, here's the latest bug that I noticed (dmd 2.094):

mixin template X() { int x; }

struct A { mixin X; int x; } // <- that compiles!

int main() {
    import std.stdio;
    writeln(A.sizeof);       // => 8
    writeln(A.id.offsetof);  // => 4
}

On Wed, Mar 10, 2021 at 05:59:56PM +0000, VF via Digitalmars-d wrote: [...]
> Speaking of bugginess, here's the latest bug that I noticed (dmd 2.094):
> 
> mixin template X() { int x; }
> 
> struct A { mixin X; int x; } // <- that compiles!

This is not a bug. It's a feature. (Although its value is debatable.) Mixins exist in separate namespaces, which can be useful if you have multiple mixins that declare the same identifier. Note that there's an optional identifier after `mixin X` that can be used to disambiguate between the two instances of `x`, e.g.:

	struct A {
		mixin X x2;
		int x;
	}

	A.x2.x = 1;
	a.x = 2;


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi

On Wednesday, 10 March 2021 at 17:59:56 UTC, VF wrote:
> Speaking of bugginess, here's the latest bug that I noticed (dmd 2.094):
>
> mixin template X() { int x; }
>
> struct A { mixin X; int x; } // <- that compiles!

That's not a bug, it is working by design and it is a very useful design, allowing specialization of public members while keeping state of private members.