June 29, 2020
On Monday, 29 June 2020 at 12:17:57 UTC, Russel Winder wrote:
> On Mon, 2020-06-29 at 10:31 +0000, IGotD- via Digitalmars-d-announce wrote:
> Another rant…
>
> …batteries included standard libraries are a thing of the 1990s and earlier. They are a reflection of pre-Internet thinking. You got a language distribution, and everything else was home grown.
>
> Now we have the Internet you can get libraries via download. Languages come with the minimal library needed to function and all else is gettable. Go, Rust, Python, and other languages have this (even though Python still has a batteries included standard library). C++ has moved on to this idea; Conan (or other system) hasn't really caught on in C++ circles. Ditto Fortran, still using pre-2000 thinking.

And that is completely wrong headed. Internet is not always directly accessible. There are a lot of companies that restrict access to the Internet for their security sensible servers, intranets etc. University people often have no clue what is standard in the corporate or the public office world. To give an example from the EU Commission. A good portion of our servers are isolated on an Intranet with very restricted access to the Internet via proxys for which access has to be requested for to the IT service. Out Intranet is deployed over different sites in Europe but the trafic is not routed over the Internet but over specialized network reserved for public institutions in Europe. The few bridges to the Internet in that network are surveilled like Fort Knox. There are also special rooms throughout our premises that are not even connected to the Intranet. Building software for these special machines has become a real challenge nowadays.
These security issues are not even the strictest I've seen or heard of here in Luxembourg with all its banking companies.

No, Internet is not always as easy peasy and having a language that can live alone and provide quite a lot of features without always calling home is a good thing.
That's why I always ranted several versions ago when Visual Studio was nearly forced upon the user. Visual Studio and all Microsoft stuff is extremely difficult to install with a poor Internet connection (the setup didn't even accept a proxy).

Sorry, my rant.



June 29, 2020
On Monday, 29 June 2020 at 12:17:57 UTC, Russel Winder wrote:
> Of course C++ is now really a niche language used by those who still use it and do not move on to more modern languages!

I am a C++ developer. I do want to move to a modern language, but there is no one that fits my needs.
Rust has a very promising ownership-borrowing concept but the lack of OOP and its awful syntax (mostly because of lifetimes) make it a no go for me.
Go is just an oversimplified language. No generics/teplates in 2020, seriously?
D has a GC. If you turn it off you lose dynamic/associative arrays, classes, probably something else. Why would I even want to use such language at all? It's much easier to stay with C++ this way, since it has lots of C/C++ libraries, IDEs, tools, broad community, support of big companies.

> The problem is backward compatibility. Every new feature in C++ requires backward compatibility with all previous C++, leading to a more and more complex language.

Totally agree. It would be much better if C++ was redesigned from scratch, dropping backward compatibility and making things better: explicit constructors/operators by default, default-initialized variables, const by default, and maybe even move semantics by default. You can explicitly copy an object if you want, but only when you really need it. We don't need 3 ways of initialization, lots of different reference types, implicit casts between different integer types, interpreting arrays as pointers, etc.

> Clearly Modern C++, aka C++11, was a great innovation and step forward. C++14, C++17, and I guess C++20 move the language forward.

C++20 is a big improvement at least because of concepts, coroutines, and ranges.

> On the other hand people are stopping using C++ in favour of Go, Rust, Python, but it seems not D.

Of course, since D doesn't look like a mature language. I've been following it for many years and it doesn't really improve. It looks just like a bunch of different things/concepts put together. Many things are stalled without of any progress because there is no consensus.
The entire DIP process is not good. There is no way to find the current DIP status, no way to learn when and whether it's going to be implemented or not. Have you noticed such questions in the forum recently?
The current status of the language is unclear. Sometimes there is only one way to find out why it behaves like it does: to ask in this forum. And you may not like the answers. D has transitive const, but what if I should lazy evaluate/cache a value or use a mutex? If I shouldn't use const, how should I emphasize the intention to pass a pointer only for reading? How can I be sure that my class invariant is not compromised? Also, there is the shared attribute, but it isn't designed nor implemented well. Lots of questions, no solutions. D is intended to be a C++ replacement, but it doesn't explain to C++ programmers how to change their way of thinking. I'd appreciate if there was a document that explains typical tasks and ways to get them done in D for the C++ dummies, like me.
Maintainers don't like to make breaking changes when they are required. Come on guys, it's called an evolution. That's why C++ is so overcomplicated right now. It tries to keep backward compatibility at all costs. I hope you don't want D to get into the same situation? Any modern language requires a chance to evolve. Sometimes you just have to break something. And making it once in a year (or 2-3 years) doesn't look like a bad option to me.
June 29, 2020
On Monday, 29 June 2020 at 15:45:48 UTC, Dagmar wrote:
> D has a GC. If you turn it off you lose dynamic/associative arrays, classes, probably something else.

You just have to construct them with a function instead of with the built-in `new` operator. (Well, associative array will need a library solution picked too, but the rest work build in if you construct them differently.)

It is very easy to do, just perhaps not well documented.
June 29, 2020
On Monday, 29 June 2020 at 15:44:38 UTC, Patrick Schluter wrote:
> [snip]
>
> And that is completely wrong headed.

+1

As much as I'm sympathetic to the arguments for a slim standard library, the amount of problems I've had in a corporate setting trying to get libraries installed behind firewalls/proxies makes me glad for the larger one. Until a few years ago, I had to manually download every R library and every single one of their dependencies and manage them myself. It's one reason I really like run.dlang.org. I've never had a problem with it.

Of course, I see nothing wrong with a high bar for entry into the standard library or the sort of promotion/relegation-type approach I've heard on the forums.
June 29, 2020
On Monday, 29 June 2020 at 16:47:27 UTC, jmh530 wrote:
> On Monday, 29 June 2020 at 15:44:38 UTC, Patrick Schluter wrote:
>> [snip]
>>
>> And that is completely wrong headed.
>
> +1
>
> As much as I'm sympathetic to the arguments for a slim standard library, the amount of problems I've had in a corporate setting trying to get libraries installed behind firewalls/proxies makes me glad for the larger one. Until a few years ago, I had to manually download every R library and every single one of their dependencies and manage them myself. It's one reason I really like run.dlang.org. I've never had a problem with it.
>
> Of course, I see nothing wrong with a high bar for entry into the standard library or the sort of promotion/relegation-type approach I've heard on the forums.

All packages I install on our Linux servers, I have to compile them by source. All the default paths used by the packages are readonly. So, everything with prefix, all dependencies. The machine with an outdated gcc (4.4.7). In that configuration, it is impossible to build a recent dmd.
Fortunately I managed to get an alternative proxy access that managed to download the bootstrap d compiler.


June 29, 2020
On Mon, 2020-06-29 at 12:41 +0000, Paulo Pinto via Digitalmars-d-announce
wrote:
[…]
> 
> Concepts, coroutines, and modules are already in ISO C++20.

Only once the standard is voted in.  :-)

Also ranges are in I believe.

> And co-routines are in a much better story than the incompatible runtimes currently existing for Rust async/await story.

I have not used C++ co-routines, but having used Rust co-routines, they seem fine. You need to make good on your negative criticism – which I would like to hear.

> Rust still needs to improve a lot on its tooling and ecosystem to cover many of the scenarios we use C++ for, even if is safer.

I can believe that may be true for others, but for me JetBrains CLion, Rustup, and Cargo make for an excellent environment. crates.io works very well – better than CLion, CMake, and lots of manual hacking around to get libraries for C++.

> Already the fact that it lacks an ISO standard is a no go in many domains.

That is a choice for those organisations. I am guessing those organisations do not use Java, D, Python, etc.

> I guess you mean using Python as glue for GPGU libraries written in C++.

In C, but yes. Though I haven't done it in a while now.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



June 29, 2020
On Monday, 29 June 2020 at 18:29:54 UTC, Russel Winder wrote:
> On Mon, 2020-06-29 at 12:41 +0000, Paulo Pinto via Digitalmars-d-announce
> wrote:
> […]
>> 
>> Concepts, coroutines, and modules are already in ISO C++20.
>
> Only once the standard is voted in.  :-)
>
> Also ranges are in I believe.
>
>> And co-routines are in a much better story than the incompatible runtimes currently existing for Rust async/await story.
>
> I have not used C++ co-routines, but having used Rust co-routines, they seem fine. You need to make good on your negative criticism – which I would like to hear.


Rust has only standardized part of the async/await story, the asynchronous
runtime is not part of the standard library, so currently it is impossible to write code that works flawlessly across the existing runtimes.

https://stjepang.github.io/2020/04/03/why-im-building-a-new-async-runtime.html

Additionally there are still rough edges with lifetimes across async/await calls.

>
>> Rust still needs to improve a lot on its tooling and ecosystem to cover many of the scenarios we use C++ for, even if is safer.
>
> I can believe that may be true for others, but for me JetBrains CLion, Rustup, and Cargo make for an excellent environment. crates.io works very well – better than CLion, CMake, and lots of manual hacking around to get libraries for C++.

The typical scenarios where we would use GPGPU shaders, iDevices, Android and Windows drivers, Arduino, SYCL, DPC++, Unreal, XBox/PS/Switch SDKs, ...

>
>> Already the fact that it lacks an ISO standard is a no go in many domains.
>
> That is a choice for those organisations. I am guessing those organisations do not use Java, D, Python, etc.

Java has a standard to guide for, updated for each language release.

So it doesn't need to be ISO, can be ECMA, or some other formal writen  specification, with multiple vendor implementations.

>
>> I guess you mean using Python as glue for GPGU libraries written in C++.
>
> In C, but yes. Though I haven't done it in a while now.


June 29, 2020
On 6/29/20 8:45 AM, Dagmar wrote:

> I am a C++ developer.

I used to be a C++ developer; luckily, I primarily write in D these days. (I can still code in C++ and will have to do so again soon.)

> I do want to move to a modern language, but there
> is no one that fits my needs.
[...]
> Go is just an oversimplified language. No generics/teplates in 2020,
> seriously?

+1 And it's fascinating how they sold all the shortcomings as benefits. Amazing!

> D has a GC.

Coming from C++, I was a die-hard "deterministic destruction" guy and it took me a long time to embrace GC. Now I know GC is pure help. GC is no more issue than any other engineering decisions.

> If you turn it off you lose dynamic/associative arrays,
> classes, probably something else.

Then don't turn it off. :)

I understand there are programs where an undeterministic delay in processing is unacceptable but those programs all run on real-time operating systems anyway, right? ;)

> Why would I even want to use such
> language at all?

For practicality. For getting things done.

> It's much easier to stay with C++ this way, since it
> has lots of C/C++ libraries, IDEs, tools, broad community, support of
> big companies.

It requires a strong C++ mindset to take GC as a liability and accept C++ complexities like the following one as manageable:

OOPS: :) I fail to find a reference table that explains implicitly or explicitly deleted or defaulted fundamental C++ operations like the copy constructor.

Yeah, accepting that kind of complexity but rejecting the GC is interesting. (I am not directing this to you but to most C++ programmers.)

> Of course, since D doesn't look like a mature language. I've been
> following it for many years and it doesn't really improve. It looks just
> like a bunch of different things/concepts put together.

That may be true for many languages but when it comes to getting things done I find D much more productive, manageable, easier, etc. etc. compared to C++. C++ has only one thing over D: Many smart people are already using C++.

> Many things are
> stalled without of any progress because there is no consensus.
> The entire DIP process is not good. There is no way to find the current
> DIP status, no way to learn when and whether it's going to be
> implemented or not. Have you noticed such questions in the forum recently?
> The current status of the language is unclear. Sometimes there is only
> one way to find out why it behaves like it does: to ask in this forum.
> And you may not like the answers.

> D has transitive const, but what if I
> should lazy evaluate/cache a value or use a mutex?

Although I agree that transitive const is the correct feature, I too find it difficult.

> If I shouldn't use
> const, how should I emphasize the intention to pass a pointer only for
> reading? How can I be sure that my class invariant is not compromised?
> Also, there is the shared attribute, but it isn't designed nor
> implemented well. Lots of questions, no solutions. D is intended to be a
> C++ replacement, but it doesn't explain to C++ programmers how to change
> their way of thinking.

There is this dated document:

  https://dlang.org/articles/cpptod.html

Although dated, that document should be sufficient to jump to D from C++. :)

> Maintainers don't like to make breaking changes when they are required.
> Come on guys, it's called an evolution.

Interestingly, one of the criticism D gets is how it evolves with breaking changes. :)

> That's why C++ is so
> overcomplicated right now. It tries to keep backward compatibility at
> all costs. I hope you don't want D to get into the same situation? Any
> modern language requires a chance to evolve. Sometimes you just have to
> break something. And making it once in a year (or 2-3 years) doesn't
> look like a bad option to me.

I agree.

Ali

June 29, 2020
On Monday, 29 June 2020 at 15:45:48 UTC, Dagmar wrote:
> D has a GC. If you turn it off you lose dynamic/associative arrays, classes, probably something else.

This is the outside perception of the way things are.

In reality you can actually disable the GC and still use:
- classes
- associative arrays (dplug:core)
- dynamic arrays if you manage their lifetime

So discarding D because it has a GC is an unfortunate common idea, that isn't really confirmed by experience: none of industrial users have had intractable problems with it.7

If anything, a GC is a global owner that can avoid some copies, hence... allocation.
June 29, 2020
On Monday, 29 June 2020 at 22:23:57 UTC, Guillaume Piolat wrote:
>
> In reality you can actually disable the GC and still use:
> - classes
> - associative arrays (dplug:core)
> - dynamic arrays if you manage their lifetime
>

Honestly, a guide how to do this would be very helpful. I'm particularly interested in how managing the lifetime of dynamic arrays in order to avoid GC means in practice, or are you referring to "dynamic arrays" as slices?