On Wednesday, 22 August 2018 at 11:59:37 UTC, Paolo Invernizzi wrote:
> Just found by chance, if someone is interested [1] [2].
>
> /Paolo
>
> [1] https://gitlab.com/mihails.strasuns/blog/blob/master/articles/on_leaving_d.md
> [2] https://blog.mist.global/articles/My_concerns_about_D_programming_language.html

Two things:

1. from the blog "You can't assume that next compiler upgrade won't
suddenly break your project or any of its transitive dependencies."

2. it took till 2018 to fix this: https://issues.dlang.org/show_bug.cgi?id=16739

As to 1.: this is my biggest fear and chagrin: with every new version my code might break. And new versions come quite frequently. Having to spend time fixing what wasn't broke a week ago is a nightmare.

As to 2: just keeps you from writing code

For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency.

I've been working with Java recently and although it is not an exciting language, it does the job and it does it well. You can rely on it to get the job done - and get it done fast. And you know that your code will still work next week, month or in 5 years. In everyday programming life you don't care about the latest fancy features. Imo, D should slow down, take inventory, do some spring cleaning and work on useful libraries and a sound ecosystem. I don't care what color the bike shed is as long as there are bikes in there that actually work.

Atm, I'm not considering D for any important and or big projects.

On Friday, 24 August 2018 at 13:04:28 UTC, Chris wrote:
> I've been working with Java recently and although it is not an exciting language, it does the job and it does it well. You can rely on it to get the job done - and get it done fast. And you know that your code will still work next week, month or in 5 years. In everyday programming life you don't care about the latest fancy features. Imo, D should slow down, take inventory, do some spring cleaning and work on useful libraries and a sound ecosystem. I don't care what color the bike shed is as long as there are bikes in there that actually work.
>
> Atm, I'm not considering D for any important and or big projects.

There is exactly where I am - I am using Java (and more recently Python) for serious stuff.

I am however in favour of D moving fast (that is why many Java programmers moved to Kotlin/Scala!). The only problem with D is that there should be stable release of D2 (two times a year, like Fedora for an example), and this stable release gets only security updates and bug-fixes!

I know this would require someone to maintain all this (it is a full-time job!)...

On Friday, August 24, 2018 6:05:40 AM MDT Mike Franklin via Digitalmars-d wrote:
> > You're basically trying to bypass the OS' public API if you're trying to bypass libc.
>
> No I'm trying to bypass libc and use the OS API directly.

And my point is that most OSes consider libc to be their OS API (Linux doesn't, but it's very much abnormal in that respect). Trying to bypass it means reimplementing core OS functionality and risking all of the bugs that go with it. It's also _far_ less portable - especially on *nix systems where the POSIX API gives you what you need in a mostly cross-platform manner (whereas syscalls aren't cross-platform at all). Trying to skip libc to call syscalls directly means that D programs risk not acting like programs written in other languages doing the same thing, and it seriously increases the maintenance cost, because then we have to worry about implementing core libc functionality that we currently get simply by linking against libc.

I honestly don't see how attempting to divorce druntime from libc does anything but increase the amount of work that we have to do and increase the likelihood that basic OS functionality is going to be buggy, since we will have then reimplemented it rather than using the same core OS functionality that everyone else is using.

If you're talking about avoiding libc functions like strcmp that's one thing, but if you're talking about reimplementing stuff that uses syscalls, then honestly, I think that you're crazy. Even if we were overflowing with extra manpower, I would think that that was a terrible idea, and given that we're _not_ overflowing with extra manpower, it's an even worse idea.

- Jonathan M Davis

On 24/08/18 13:43, nkm1 wrote:
> 
> I think Walter was talking more about "scope (failure) destroy(this)" at the top of all your structs? I don't know if it has some gotchas, though (as I don't use RAII in D...).
> 

No, unlike what I suggest, that doesn't work without carefully reviewing every single place you put it to see whether the constructor actually supports destructing a partially constructed object.

Shachar

On Friday, 24 August 2018 at 13:17:11 UTC, Dejan Lekic wrote:
> On Friday, 24 August 2018 at 13:04:28 UTC, Chris wrote:
>
> There is exactly where I am - I am using Java (and more recently Python) for serious stuff.

So I'm not alone.

> I am however in favour of D moving fast (that is why many Java programmers moved to Kotlin/Scala!).
[snip]

Yes, but D is already there in many ways. Other languages (like Java) are trying to catch up with D. And like in Java, new features should be a bonus, something you may use later, but not break existing code.

On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote:

> I think that you're crazy.

No, I just see more potential in D than you do.

Mike

On Friday, 24 August 2018 at 13:34:57 UTC, Shachar Shemesh wrote:
> On 24/08/18 13:43, nkm1 wrote:
>> 
>> I think Walter was talking more about "scope (failure) destroy(this)" at the top of all your structs? I don't know if it has some gotchas, though (as I don't use RAII in D...).
>> 
>
> No, unlike what I suggest, that doesn't work without carefully reviewing every single place you put it to see whether the constructor actually supports destructing a partially constructed object.
>
> Shachar

So I guess you're saying you also use "= void" as default initializer for some things. Otherwise, it's already a requirement that all default-initialized things should be destructible...
Yeah, I do agree that these kinds of things are not very well supported by D. I do not agree that it means the language is doomed (from a techincal standpoint, at least). Moving in a more Java-esque direction ("Fast like C++ but with good GC" (so, in reality, slower than C++ but faster than JVM)) would be a reasonable strategy for D. Seems like it's not going to happen, though.

On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote:
>
> I honestly don't see how attempting to divorce druntime from libc does anything but increase the amount of work that we have to do and increase the likelihood that basic OS functionality is going to be buggy, since we will have then reimplemented it rather than using the same core OS functionality that everyone else is using.

+1

Now that the leadership talks about Leverage points
http://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/

When rated from 1 to 9 this is a 10, it likely brings negative value.

This is even worse if D_SIMD version of AVX is implemented because of that, loosing precious Walter-time (an illiquid asset) for a non-existent fraction of users: also a 10.

Whereas merely adding colors to DUB would be a 7.


I feel even more uneasy by all that @safe focus, as if native programmers started to care overnight. No, we still don't. People say they do.

On Friday, 24 August 2018 at 13:04:28 UTC, Chris wrote:

> For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency.

I've started moving some things to other languages myself. The problem is that D, in its current form, has a process that is specially optimized to make it as unusable as possible.

1. There will be no D version 3.
2. There will be no major breaking changes like autodecoding unless we think they're important (and there are no guidelines on what's important, just whatever comes to someone's mind on a particular day).
3. There are many trivial breaking changes made, and they can come in any release.
4. The more releases the better.

You simply can't share a D program with anyone else. It's an endless cycle of compiler upgrades and figuring out how to fix code that stops compiling. It doesn't work for those of us that are busy. Why there is not a stable branch with releases once a year is quite puzzling. (And no, "just use the old compiler" is not an answer.)

On 25/08/2018 4:00 AM, bachmeier wrote:
> On Friday, 24 August 2018 at 13:04:28 UTC, Chris wrote:
> 
>> For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency.
> 
> I've started moving some things to other languages myself. The problem is that D, in its current form, has a process that is specially optimized to make it as unusable as possible.
> 
> 1. There will be no D version 3.
> 2. There will be no major breaking changes like autodecoding unless we think they're important (and there are no guidelines on what's important, just whatever comes to someone's mind on a particular day).
> 3. There are many trivial breaking changes made, and they can come in any release.
> 4. The more releases the better.
> 
> You simply can't share a D program with anyone else. It's an endless cycle of compiler upgrades and figuring out how to fix code that stops compiling. It doesn't work for those of us that are busy. Why there is not a stable branch with releases once a year is quite puzzling. (And no, "just use the old compiler" is not an answer.)

Hmm, would a every 2 year LTS be reasonable?
We're currently doing about 1 major every 2 months now.

This can be used for boot strapping purposes too, while keeping the number of compilers required minimal.