On Thursday, 20 July 2017 at 15:40:04 UTC, Wulfklaue wrote:

> After going back recently to good old Pascal. More specific the freepascal compiler combined with Visual Studio Code + Omnipascal, ... it felt just more easy.
>
> In a few days time after reading up all the details, i got myself a nice multithreaded http server build without using any standardized framework. Sure it is missing a lot of functionality but i felt more proud writing it in Pascal, then i did writing the same in D
>
> The easy to write cross platform Dlls. The more clean design to use those DLL loading without relying on dlsym all the time. The time wasted trying to figure that out in D to get it working correctly. *uch* ...
>
> While the language is indeed more "verbose" ( not that much ), the compiler does less checking, it just is more "fun". D feels more like work. Now it also helps that there is massive amount of more documentation for pascal out there, even if its old.


> At the same Pascal compiles in 0.1 second, give me the speed similar(actually faster) than D, cross platform support, no need to mess with different compiler ( dmd for compile, ldc for speed ). Its even more TTD then D :)
>
> Windows: Download, install, runs. It integrates perfectly with the Visual Studio Code plugin. Linux a simple apt-get command. No need to download a deb or run a shell script.
>

i did the same, but use for windows programs AWD Modula. its free, compiles fast and is used commercially.
i QUIT on D, since you can't install and use, for all the reasons you describe. a consequence for me was to warn people at work to use it.

On Thursday, 20 July 2017 at 15:40:04 UTC, Wulfklaue wrote:


> Windows: Download, install, runs. It integrates perfectly with the Visual Studio Code plugin. Linux a simple apt-get command. No need to download a deb or run a shell script.
>

i did the same, but use for windows programs AWD Modula. its free, compiles fast and is used commercially.
i QUIT on D, since you can't install and use, for all the reasons you describe. a consequence for me was to warn people at work to use it.

On Thursday, 20 July 2017 at 16:15:43 UTC, porter wrote:
> i did the same, but use for windows programs AWD Modula. its free, compiles fast and is used commercially.

AWD Modula? You mean Modula 2?

On Thursday, 20 July 2017 at 17:04:14 UTC, Wulfklaue wrote:
> On Thursday, 20 July 2017 at 16:15:43 UTC, porter wrote:
>> i did the same, but use for windows programs AWD Modula. its free, compiles fast and is used commercially.
>
> AWD Modula? You mean Modula 2?

yes

https://www.modula2.org/adwm2/

On Friday, 14 July 2017 at 13:29:30 UTC, Joakim wrote:
> Yes, D's compile-time regex are still the fastest in the world.
>  I've been benching it recently for a marketing-oriented blog post I'm preparing for the official D blog, std.regex beats out the top C and Rust entries from the benchmarks game on linux/x64 with a single core:
>
> http://benchmarksgame.alioth.debian.org/u64q/regexredux.html
> https://github.com/joakim-noah/regex-bench
>
> D comes in third on Android/ARM, but not far behind, suggesting it would still be third on that list if run with a bunch of other languages on mobile.  Dmitry thinks it might be alignment issues, the bane of cross-platform, high-performance code on ARM, as he hasn't optimized his regex code for ARM.

Interesting. A few months ago I wanted to sell ctRegex as the fastest one in a presentation, but in my benchmarks (based on [1]) I found it to be of equal speed or slower than boost::regex (LDC vs Clang).

I've got to take a look at your benchmarks, and repeat mine to check again if I didn't mess something up.

[1] http://lh3lh3.users.sourceforge.net/reb.shtml

On Friday, 21 July 2017 at 13:25:32 UTC, Adrian Matoga wrote:
> On Friday, 14 July 2017 at 13:29:30 UTC, Joakim wrote:
>> Yes, D's compile-time regex are still the fastest in the world.
>>  I've been benching it recently for a marketing-oriented blog post I'm preparing for the official D blog, std.regex beats out the top C and Rust entries from the benchmarks game on linux/x64 with a single core:
>>
>> http://benchmarksgame.alioth.debian.org/u64q/regexredux.html
>> https://github.com/joakim-noah/regex-bench
>>
>> D comes in third on Android/ARM, but not far behind, suggesting it would still be third on that list if run with a bunch of other languages on mobile.  Dmitry thinks it might be alignment issues, the bane of cross-platform, high-performance code on ARM, as he hasn't optimized his regex code for ARM.
>
> Interesting. A few months ago I wanted to sell ctRegex as the fastest one in a presentation, but in my benchmarks (based on [1]) I found it to be of equal speed or slower than boost::regex (LDC vs Clang).
>
> I've got to take a look at your benchmarks, and repeat mine to check again if I didn't mess something up.
>
> [1] http://lh3lh3.users.sourceforge.net/reb.shtml

The boost C++ benchmark run in the link I gave says it's more than 10X slower than the top C one I found D to be faster than, so I didn't bother with it.  Maybe you can speed it up:

http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexredux&lang=gpp&id=3

As for your benchmark, I'd be surprised if ctRegex wouldn't beat out Boost given how well it does against the faster PCRE in the fasta-dna one I tried, but all these microbenchmarks only look at particular features of a full regex engine, so it's always possible ctRegex is slower in others.

On Friday, 21 July 2017 at 13:50:24 UTC, Joakim wrote:
> On Friday, 21 July 2017 at 13:25:32 UTC, Adrian Matoga wrote:
>> On Friday, 14 July 2017 at 13:29:30 UTC, Joakim wrote:
>>> [...]
>>
>> Interesting. A few months ago I wanted to sell ctRegex as the fastest one in a presentation, but in my benchmarks (based on [1]) I found it to be of equal speed or slower than boost::regex (LDC vs Clang).
>>
>> I've got to take a look at your benchmarks, and repeat mine to check again if I didn't mess something up.
>>
>> [1] http://lh3lh3.users.sourceforge.net/reb.shtml
>
> The boost C++ benchmark run in the link I gave says it's more than 10X slower than the top C one I found D to be faster than, so I didn't bother with it.  Maybe you can speed it up:
>
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexredux&lang=gpp&id=3
>
> As for your benchmark, I'd be surprised if ctRegex wouldn't beat out Boost given how well it does against the faster PCRE in the fasta-dna one I tried, but all these microbenchmarks only look at particular features of a full regex engine, so it's always possible ctRegex is slower in others.

We disabled the Kickstart engine temporarily as there where issues with CTFE [1], this means that until newCTFE is out runtime will be faster in most cases and it won't perform nicely in benchmark. However, newCTFE is almost finished, and with a bit of luck we see it in master soon.

[1] https://github.com/dlang/phobos/pull/4995

On Friday, 14 July 2017 at 08:57:17 UTC, Wulfklaue wrote:
> https://blog.sourced.tech/post/language_migrations/
>
> A recent article where github programming languages popularity and migration got analysed was very interesting but it showed one noticeable thing:
>
> [...]

Unless some miracle happens and makes the GC better by preventing stop-the-world, or gets rid of the GC, D will not get any more attention.

On Sat, 2017-07-22 at 13:27 +0000, aedt via Digitalmars-d wrote:
> 
[…]
> Unless some miracle happens and makes the GC better by preventing stop-the-world, or gets rid of the GC, D will not get any more attention.

D without the GC isn't at all interesting, might as well use Go in that case. So D only gets traction if it keeps a GC.

Except for the "actually on the metal" people who can prove they cannot survive if there is a GC, and D does that already – but without the standard library.

-- 
Russel.
=============================================================================
Dr Russel Winder     t:+44 20 7585 2200   voip:sip:
russel.winder@ekiga.net
41 Buckmaster Road   m:+44 7770 465 077   xmpp:russel@winder.org.uk
London SW11 1EN, UK  w: www.russel.org.uk skype:russel_winder

On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote:
> Unless some miracle happens and makes the GC better by preventing stop-the-world

I have yet to see a (working, correct) non-STW GC that doesn't make other trade offs not acceptable for D (extra thread(s), memory barriers for all writes, etc.).
There's room for improvement of the current GC, but I sincerely doubt we will see one that's not STW.

> or gets rid of the GC

And remove one of the primary reasons why one doesn't have to prototype in some script language (e.g. python)? No thanks.