August 11, 2021

On Wednesday, 11 August 2021 at 11:33:42 UTC, Johan wrote:

>

On Tuesday, 10 August 2021 at 00:53:29 UTC, Brian Tiffin wrote:

>

So it's a question. What is a reasonable life expectancy for the projects I start in D today?

Very much depends on the type of project. How much do you depend on new features (likely to change), how much do you depend on library code, how much do you depend on ABI details, how much are you working around current language/compiler issues...?

At Weka, thusfar any new compiler means compilation failures. It is a demanding codebase.
Some reasons for failures: workarounds for compiler bugs, ABI dependencies, template attribute deduction deltas, dependence on druntime internals, new compiler bugs, change of language semantics (sometimes intended, but also often unintended), no way to disable/enable specific warnings/deprecations, ...
On top of that, performance may change too with compiler version, so even if the build succeeds that does not mean the program still functions within the required performance constraints.
Keeping the code compatible with multiple frontends is a large burden, currently avoided by specifying the compiler version in the codebase and using that exact compiler on build systems and developer's machines (i.e. each dev will have multiple compilers on his machine, automatically downloaded and used by build system). Updating the compiler to a new version is a lengthy process. Weka is currently at LDC 1.24 (with Weka modifications).

-Johan

Funkwerk: this is what we do as well. All tools involved in a build are pinned at a fixed version per repository. Anyone doing enterprise development in D should do this as a matter of course; without reproducible builds, how can you be sure you can react effectively when a deployed system breaks? You don't want to mess around with deprecations when a customer's system is down.

We generally update DMD about twice a year, in jumps of four minor versions, to reduce the cost of fixing compiler issues and deprecations across lots of projects.

Current DMD versions used in repos:

2.094 = 37
2.090 = 14
2.086 = 16
2.082 = 11
2.077 = 8

The older repos are generally not actively maintained though.

August 11, 2021

On Wednesday, 11 August 2021 at 11:33:42 UTC, Johan wrote:

>

… specifying the compiler version in the codebase and using that exact compiler on build systems and developer's machines (i.e. each dev will have multiple compilers on his machine, automatically downloaded and used by build system).

That’s what we plan to do as well. Is that accomplished with off the shelf tooling, or largely scripted in house? I’d like to make this accessible with as little effort as possible. Imagine checking out any project at any revision and it builds without intervention at any time.

— Bastiaan.

August 11, 2021

On Wednesday, 11 August 2021 at 14:22:31 UTC, Bastiaan Veelo wrote:

>

On Wednesday, 11 August 2021 at 11:33:42 UTC, Johan wrote:

>

… specifying the compiler version in the codebase and using that exact compiler on build systems and developer's machines (i.e. each dev will have multiple compilers on his machine, automatically downloaded and used by build system).

That’s what we plan to do as well. Is that accomplished with off the shelf tooling, or largely scripted in house? I’d like to make this accessible with as little effort as possible. Imagine checking out any project at any revision and it builds without intervention at any time.

It is scripted in-house.
There's some extra trickery involved because of the modified LDC version, and to give some small freedom in slightly different versions on dev's machines and CI/build system (although unused atm).

-Johan

August 11, 2021

On Wednesday, 11 August 2021 at 14:22:31 UTC, Bastiaan Veelo wrote:

>

On Wednesday, 11 August 2021 at 11:33:42 UTC, Johan wrote:

>

… specifying the compiler version in the codebase and using
...
Imagine checking out any project at any revision and it builds without intervention at any time.

— Bastiaan.

:-)

As mentioned at the top, a COBOL guy, source code from 1972 just works. COBOL programmers live in that imaginary world.

Ok, that's exaggerating the truth, but it's the disappointing exception that is the exception, not the rule. The rule is, code it now and it compiles and works, in perpetuity.

And thanks for the hints on how to go about increasing the life expectancy for D source codes.

To be honest, I'm hoping to be able to assume that D source will be as resilient to the ever changing surrounding environments for as long as I'd assume C source to be. Source code should age gracefully, not fearing each and every revision of build tools or run-time support libraries. Yes, you retest after upgrades, but the assumption should be more life in a newly renovated house, not assuming you have to count the number of broken fingers that need attention before getting back to work. :-)

Have good, make well.

August 12, 2021

On Wednesday, 11 August 2021 at 19:40:36 UTC, Brian Tiffin wrote:

>

On Wednesday, 11 August 2021 at 14:22:31 UTC, Bastiaan Veelo wrote:

>

On Wednesday, 11 August 2021 at 11:33:42 UTC, Johan wrote:

>

… specifying the compiler version in the codebase and using
...
Imagine checking out any project at any revision and it builds without intervention at any time.

— Bastiaan.

:-)

As mentioned at the top, a COBOL guy, source code from 1972 just works. COBOL programmers live in that imaginary world.

Ok, that's exaggerating the truth, but it's the disappointing exception that is the exception, not the rule. The rule is, code it now and it compiles and works, in perpetuity.

And thanks for the hints on how to go about increasing the life expectancy for D source codes.

To be honest, I'm hoping to be able to assume that D source will be as resilient to the ever changing surrounding environments for as long as I'd assume C source to be. Source code should age gracefully, not fearing each and every revision of build tools or run-time support libraries. Yes, you retest after upgrades, but the assumption should be more life in a newly renovated house, not assuming you have to count the number of broken fingers that need attention before getting back to work. :-)

Have good, make well.

Personally speaking, I am strongly against this.

I think that works for a compact, well-defined language that is "done", that generally works well, or at least good enough that you can live with the corner-cases. Like C. In comparison, D is to some large extent also an exploration of language design, an attempt to see what works and what doesn't, and when you lean yourself out of the window like that you have to be able and willing to course correct, to say "well we tried that but it didn't work out", or you get stuck in mediocrity.

D is too big and too speculative to support true long-term stability. As a compromise, we have the deprecation mechanism, which gives you early warning for which parts are going away in future versions. I am very glad for this mechanism, and honestly think the rate of change of D could even be a bit higher than it is today, maybe up to twice as fast.

August 12, 2021

On Thursday, 12 August 2021 at 08:52:29 UTC, FeepingCreature wrote:

>

On Wednesday, 11 August 2021 at 19:40:36 UTC, Brian Tiffin

>

...
To be honest, I'm hoping to be able to assume that D source will be as resilient to the ever changing surrounding environments for as long as I'd assume C source to be. Source code should age gracefully, not fearing each and every revision of build tools or run-time support libraries. Yes, you retest after upgrades, but the assumption should be more life in a newly renovated house, not assuming you have to count the number of broken fingers that need attention before getting back to work. :-)

Have good, make well.

Personally speaking, I am strongly against this.

I think that works for a compact, well-defined language that is "done", that generally works well, or at least good enough that you can live with the corner-cases. Like C. In comparison, D is to some large extent also an exploration of language design, an attempt to see what works and what doesn't, and when you lean yourself out of the window like that you have to be able and willing to course correct, to say "well we tried that but it didn't work out", or you get stuck in mediocrity.

D is too big and too speculative to support true long-term stability. As a compromise, we have the deprecation mechanism, which gives you early warning for which parts are going away in future versions. I am very glad for this mechanism, and honestly think the rate of change of D could even be a bit higher than it is today, maybe up to twice as fast.

I lean to stable, but don't disagree with your sentiment, FeepingCreature. COBOL is one of the very few Computer Business programming languages. It has a domain of strength, and has owned that domain since the inception of writing programs. Big monies ride on it, and computers are not the purpose of those businesses, just a tool to help run said business.

Computer Science needs and wants to evolve faster than Computer Business. But there does need to be stable or promise of stable if you want a business to invest in a technology. Except for a very few fields, computers are not the purpose of a business, just a tool to automate some tasks or speed up calculations to a point that making those calculations can happen in a reasonable time frame.

Think about D replacing the user land of a Linux distro. GNU doesn't replace cat every 4 years because it was forced on the project because a build tool changed. coreutils is maintained, yes, mostly by volunteers, but it wouldn't be GNU/Linux if the GNU part failed on every other kernel update. The keenest of programmers age out.

If a team was to try and replace coreutils with D, there would likely be an initial round of totally keen programmers, eager to try. If they succeeded and completed all the commands, the amount of keen to go back and fix things later would be greatly diminished.

coreutils-d would be a very cool thing to see. But, 7 years later it would likely be in a state of bitrot. It might not entice enough keen programmers to tweak and improve, if all the time is spent on forced maintenance due to constant upstream changes to tooling. When you can't entice the keen programmers, the keen programmers do something else. coreutils-d would start to fray, and would likely become an effort of a few critical maintainers, who will age out. coreutils will stay written in C and C++, and will compile with gcc for the foreseeable future. Decades of future added to the decades of past.

I'm loving exploring D and can see the absolutely immense potential. But, I'm doing this in my spare time at no one's expense. I'm not doing D as a person in need of hiring a team to work on a business problem or new product. Programmers are expensive, people only want to have to pay them once for each feature coded. Then pat them on the back for a job well done, and punt them from the payroll as soon as possible.

If D is ok with being used in small system programming fields with short-range life expectancy, then it could very well own the domain, and be the world class tool. In that reality, world domination is off the table.

I'd be ok with that form of D in the long term, as a hobbyist writing little throw away programs, while having a lot of fun doing it.

But I would not yet want to publish anything that might become famous, only to be chained to maintenance on a schedule randomly dictated by others. I'm a computer programmer, my attention span is counted in seconds, intermixed with long periods of deep focus that end when they end. And then it is on to the next thing. Don't like being forced by circumstance to redo a deep focus; that's supposed to be my decision of when and where, unless I've already traded my time for someone else's money, then they get to decide the where, the when, and the how.

So, I guess I'm not yet strongly for or against stable, long term, source level D. Leaning to for, I will opine as an old guy, as-is, D is not yet destined for world domination. Which is ok. A fraction of the millions of human hours spent programming every hour around the world, is still a lot of hours. Redoing hours is no fun though, and this thread is helping set expectations.

Have good, make well.

August 12, 2021

On Wednesday, 11 August 2021 at 19:40:36 UTC, Brian Tiffin wrote:

>

To be honest, I'm hoping to be able to assume that D source will be as resilient to the ever changing surrounding environments for as long as I'd assume C source to be. Source code should age gracefully, not fearing each and every revision of build tools or run-time support libraries. Yes, you retest after upgrades, but the assumption should be more life in a newly renovated house, not assuming you have to count the number of broken fingers that need attention before getting back to work. :-)

When you want as long tail as possible for your code, GDC is recommended. See https://forum.dlang.org/post/oixwnblhdxyehongfvss@forum.dlang.org

August 12, 2021
On 8/11/21 7:33 AM, Johan wrote:
> On Tuesday, 10 August 2021 at 00:53:29 UTC, Brian Tiffin wrote:
>>
>> So it's a question.  What is a reasonable life expectancy for the projects I start in D today?
> 
> Very much depends on the type of project. How much do you depend on new features (likely to change), how much do you depend on library code, how much do you depend on ABI details, how much are you working around current language/compiler issues...?
> 
> At Weka, thusfar any new compiler means compilation failures. It is a demanding codebase.
> Some reasons for failures: workarounds for compiler bugs, ABI dependencies, template attribute deduction deltas, dependence on druntime internals, new compiler bugs, change of language semantics (sometimes intended, but also often unintended), no way to disable/enable specific warnings/deprecations, ...
> On top of that, performance may change too with compiler version, so even if the build succeeds that does not mean the program still functions within the required performance constraints.
> Keeping the code compatible with multiple frontends is a large burden, currently avoided by specifying the compiler version in the codebase and using that exact compiler on build systems and developer's machines (i.e. each dev will have multiple compilers on his machine, automatically downloaded and used by build system). Updating the compiler to a new version is a lengthy process. Weka is currently at LDC 1.24 (with Weka modifications).

FWIW the situation is similar with large-scale C++ projects as well. Whenever I teach, I first ask people what version of their C++ compiler they're on - does it support C++14, C++17, etc. Many mention some really outdated release and invariably invoke the difficulty of upgrading due to compilation errors and performance issues.

Also, most of big tech hack into their C++ compiler (and some their Linux, too).
August 12, 2021
On Thursday, 12 August 2021 at 13:42:27 UTC, Andrei Alexandrescu wrote:
> On 8/11/21 7:33 AM, Johan wrote:
>> [...]
>
> FWIW the situation is similar with large-scale C++ projects as well. Whenever I teach, I first ask people what version of their C++ compiler they're on - does it support C++14, C++17, etc. Many mention some really outdated release and invariably invoke the difficulty of upgrading due to compilation errors and performance issues.
>
> Also, most of big tech hack into their C++ compiler (and some their Linux, too).

May I please request you to share how often you hear that people are still using C++98/03? Maybe using C++03 but using clang++'s non-standard extensions that allow access to C++11 features like move semantics?
August 12, 2021
On Thursday, 12 August 2021 at 13:42:27 UTC, Andrei Alexandrescu wrote:
> On 8/11/21 7:33 AM, Johan wrote:
>> On Tuesday, 10 August 2021 at 00:53:29 UTC, Brian Tiffin wrote:
>>>
>>> So it's a question.  What is a reasonable life expectancy for the projects I start in D today?
>> 
>> Keeping the code compatible with multiple frontends is a large burden, currently avoided by specifying the compiler version in the codebase and using that exact compiler on build systems and developer's machines (i.e. each dev will have multiple compilers on his machine, automatically downloaded and used by build system). Updating the compiler to a new version is a lengthy process. Weka is currently at LDC 1.24 (with Weka modifications).
>
> FWIW the situation is similar with large-scale C++ projects as well. Whenever I teach, I first ask people what version of their C++ compiler they're on - does it support C++14, C++17, etc. Many mention some really outdated release and invariably invoke the difficulty of upgrading due to compilation errors and performance issues.
>
> Also, most of big tech hack into their C++ compiler (and some their Linux, too).

Hi Andrei,
  Indeed, good to include that perspective.
Do you think that industrial C++ programming has become more standard compliant in the last ~10years ?  E.g. due to the availability of viable gcc alternative clang compiler, thus you start to notice the reliance on compiler specifics; and also perhaps due to the compiler community putting emphasis on standard compliance (even MSVC).

Regardless of standard compliance, performance deltas will remain an issue.

cheers,
  Johan

1 2
Next ›   Last »