Re: Blog post: What D got wrong

[Pjotr Prins via Digitalmars-d-announce]

On Tuesday, 18 December 2018 at 11:25:17 UTC, Jonathan M Davis 
wrote:
Of course, even if we _did_ have a solution for reversing 
attributes, slapping an attribute on the top of the module 
would still potentially be a maintenance problem, because it's 
then really easy to miss that an attribute is in effect (it's a 
problem that we've had on several occasions with druntime and 
Phobos in the few cases where attributes are mass-applied). So, 
there is no silver bullet here (though regardless of whether 
mass-applying attributes is something that should ever be 
considered good practice, we really should add a way to be able 
to reverse them).


Thanks Jonathan for your elaborate explanation. I personally have 
no problem with the attributes which - in practice - means I 
don't use them much unless I want to make sure something is nogc, 
for example. For library designers it makes sense to be explicit. 
I guess that is where the trade-off kicks in. Maybe it is just a 
feature. We argue against specifying them because other languages 
are not as explicit. It does add a little noise.

Re: Blog post: What D got wrong

[Pjotr Prins via Digitalmars-d-announce]

On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe 
wrote:

On Thursday, 13 December 2018 at 10:29:10 UTC, RazvanN wrote:
Do you honestly think that they will ever take D into account 
if @safe and immutable data will be the default?


D needs to stop chasing after what you think people think they 
want and just start being good for us.


The majority of my code is written pretty permissively - I like 
my pointers, my gotos, my GC, my exceptions. But I'm willing to 
consider the change because I actually don't think it will be 
that big of a hassle, and will be better overall. I wanna show 
you something:


/// Static convenience functions for common color names
nothrow pure @nogc @safe
static Color transparent() { return Color(0, 0, 0, 0); }


The attribute spam is almost longer than the function itself.


Isn't it the way forward that the compiler deduces these 
attributes and fills them in automatically? All these can be 
inferenced. Only when the caller wants to guarantee, say pure, it 
could add it explicitly. I read somewhere that the compiler 
already does this to some degree. And even the generated docs 
should be able to show it.

Dlang at FOSDEM 2019

[Pjotr Prins via Digitalmars-d]

D usually has a talk in the LLVM room.

There are more options, e.g., we are organizing a devroom on 
Minimalistic Languages. It may be an idea to propose one or two 
talks on minimalism. D as a betterC would be interesting.


https://libreplanet.org/wiki/FOSDEM2019-devroom-minimalism

Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)

[Pjotr Prins via Digitalmars-d]

On Sunday, 2 September 2018 at 12:07:17 UTC, Laeeth Isharc wrote:
I've only been programming since 1983 so I had the benefit of 
high level languages like BBC BASIC, C, a Forth I wrote myself, 
and Modula 3.  And although I had to write a disassembler at 
least I has assemblers built in.  Programming using a hex 
keypad is not that satisfying after a while.  It takes a long 
time to develop a language, its ecosystem and community.


Hear, hear!

Even though some languages like Julia, Rust and Go are much 
better funded than D - and their creators have excellent taste in 
different ways - they still have to go through similar 
evolutionary steps. There is no fast path. Whatever design 
decision you make, you always end up fixes bugs and corner cases. 
I was amazed how behind Rust's debugger support was last year (I 
witnessed a talk at FOSDEM). They are catching up, but it just 
goes to show...


One thing I want to add that we ought to be appreciative of the 
work people put in - much of it in their spare time. I wonder if 
W and others sometimes despair for the lack of appreciation 
they get. Guido van Rossum burning out (W, notably, was the one 
to post that here first) is a shame. Even though he created a 
language which I find less tasteful he did not deserve to be 
treated like that. Simple.

Re: Release D 2.082.0

[Pjotr Prins via Digitalmars-d-announce]

On Sunday, 2 September 2018 at 01:05:10 UTC, Martin Nowak wrote:


http://dlang.org/changelog/2.082.0.html

-Martin


gdb exception catching looks pretty useful to me!

Re: Dicebot on leaving D: It is anarchy driven development in all its glory.

[Pjotr Prins via Digitalmars-d]

On Sunday, 26 August 2018 at 03:17:06 UTC, Ali wrote:
As a realistic short term fix, I think both Andrei and Walter, 
need to streamline and be more vocal about long term plans, 
because this is obviously a source of confusion for many, and a 
source for a lot of rants


My summary is that D means different things to different people. 
D has put in the kitchen sink. It tries to please everyone which 
means it is a complex toolbox. One thing I have learnt by lurking 
in this project is how much effort goes into compiler/library 
development to make it great. NoGC and safe just show how hard 
that can be. Lots of work on corner cases. Maybe with hindsight D 
should have been less OOP and more FP (destructuring data 
anyone?), but then you lose all those who want/are used to that 
paradigm.


I use quite a few languages. For me D is the most powerful 
language I have for getting performance. Artem wrote Sambamba as 
a student


https://github.com/biod/sambamba

and it is now running around the world in sequencing centers. 
Many many CPU hours and a resulting huge carbon foot print. The 
large competing C++ samtools project has been trying for 8 years 
to catch up with an almost unchanged student project and they are 
still slower in many cases.



https://groups.google.com/forum/#!topic/sambamba-discussion/z1U7VBwKfgs


Just saying. Much better to choose D over C++. I also work on a 
C++ project and I find it to be a royal pain compared to writing 
software in D.


Note that Artem used the GC and only took GC out for critical 
sections in parallel code. I don't buy these complaints about GC.


The complaints about breaking code I don't see that much either. 
Sambamba pretty much kept compiling over the years and with 
LDC/LLVM latest we see a 20% perfomance increase. For free (at 
least from our perspective). Kudos to LDC/LLVM efforts!!


Very excited to see gdc pick up too. We need the GNU projects.

So, do we need change? You can always try and improve process and 
over the last years W have been pushing for that.


Let me state here that  D is anarchy driven development in all 
its glory (much like the Linux kernel). I believe it is great.


I think, in addition to standard packaging in Linux distros 
(which is coming), D could use more industry support (much like 
the Linux kernel). D being a performance language for software 
engineers I would look at the extremes of HPC and mobile to 
succeed. How do we wake those companies up? Especially those with 
large investments in C++. Those we should invite to Dconf.


I remember one guy at Google telling me that every time someone 
would bring up "Why don't we write this in D instead?". That was 
10 years ago. Google invested in Python and Go instead - but 
still write heaps of code in C++. Go figure.

Re: GDC with D frontend 2.081.2

[Pjotr Prins via Digitalmars-d-announce]

On Friday, 24 August 2018 at 05:35:13 UTC, Eugene Wissner wrote:
I prepared GDC/GCC 7.3.0 binaries for x86-64 Linux built on 
Ubuntu 18.04:


Thank you, this is very important work! I'll add a gdc package to 
GNU Guix (the packager for GNU) sometime soon.

Re: std.variant Is Everything Cool About D

[Pjotr Prins via Digitalmars-d-announce]

Great blog. Thanks.

Re: Updated D packages in GNU Guix for x86_64-linux, i686-linux, armhf-linux

[Pjotr Prins via Digitalmars-d-announce]

On Sunday, 11 March 2018 at 12:41:28 UTC, Johan Engelen wrote:
Kai has been working recently [1] on updating LDC 0.17.x 
(ltsmaster) to work with LLVM 6, PowerPC, AArch64, ...  You may 
want to take advantage of that activity to get better bootstrap 
compiler support for your platforms. For example by filing bug 
reports, or better: helping out with testing and fixing things 
;-)


Sure thing. Guix can support multiple versions of LLVM and build 
against those, so you can inject different dependencies (read 
versions of LLVM) in the dependency graph. I am quite keen to use 
the latest for my tools.

Updated D packages in GNU Guix for x86_64-linux, i686-linux, armhf-linux

[Pjotr Prins via Digitalmars-d-announce]

The GNU package manager updated LDC to 1.7.0 which now provides 
x86_64-linux, see https://www.gnu.org/software/guix/packages/L/. 
Runtime dependencies and build are listed at 
https://hydra.gnu.org/build/2525193#tabs-runtime-deps, including 
0.17.4 (bootstrap) and LLVM 3.8.1.


LDC 0.17.4 provides x86_64-linux, i686-linux, armhf-linux.

We aim to add D compilers for all supported architectures.

Note that GNU Guix can run on top of all Linux distributions 
because it is self-contained. Guix includes all its dependencies 
(except the kernel) and can be removed easily.

Re: Dub, Cargo, Go, Gradle, Maven

[Pjotr Prins via Digitalmars-d]

On Thursday, 15 February 2018 at 17:54:57 UTC, John Gabriele 
wrote:
Are any other languages using Guix for their 3rd-party online 
package repo? If not, why?


GNU Guile ;).


That's excellent. I remember years ago it looked like there was 
action in getting a Guile package repo going but it never 
panned out. Glad they found (and settled on) something! (Though 
 doesn't say 
anything about Guix, and I don't see anything about Guix in the 
[Guile 
manual](https://www.gnu.org/software/guile/docs/master/guile.html/)).


The Guile maintainers effectively use Guix for handling the build 
chain and dependencies.
See Andy Wingo's blog https://wingolog.org/ - section 'getting 
the goods' he discusses Guile packaging and Guix. Andy is the 
main compiler writer of Guile. The following is a bit out of 
date, but you get the idea



https://wingolog.org/archives/2015/08/04/developing-v8-with-guix.


I'd love to see an overview article explaining how the pieces 
would fit together. Would Guix work with Dub? If so, what 
specifically (on GNU/Linux) would be required to make that 
happen, and what would using such a solution look like in 
practice?


I need to write a BLOG. After the Python one.

I don't yet know enough about D and Dub to even know what 
giving Guix a shot would mean :). I'm on Debian and so use apt 
for installing software. I'll have to spend some time with the 
Guix (and Dub) docs.


I meant you can try Guix anyway. It will be a gain. I run Guix on 
top of Debian myself. I am a real Debian fan - using Debian more 
than 15 years. But when it comes to my development environment 
and my software deployment I use Guix. Debian can not handle that 
well enough.

Re: Dub, Cargo, Go, Gradle, Maven

[Pjotr Prins via Digitalmars-d]

On Thursday, 15 February 2018 at 15:52:41 UTC, John Gabriele 
wrote:
It's a bit confusing since the first thing [the Guix 
webpage](https://www.gnu.org/software/guix/) talks about 
"GuixSD", rather than the Guix tool in its own right.


Yes. We discussed that at the hackathon before FOSDEM. It is 
rather difficult to position a project that has so many use 
cases...


Wow, I didn't realize how established Guix is. It's [packages 
page](https://www.gnu.org/software/guix/packages/) boasts 6868 
available packages!


~2000 added in the last year. I am updating the ldc package to 
1.7.0 this week.


Are any other languages using Guix for their 3rd-party online 
package repo? If not, why?


GNU Guile ;). The current state is that everyone is rolling out 
some type of language support. The good news is that Guix allows 
for abstracting existing build systems. If you look at a typical 
python package you can see it leans on pip:


  
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/python.scm#n1004


The package is written in Guile scheme, but you can see it does 
not take a genius
to package something. In fact Guix can generate the actual 
package definition automatically.


We have not written something similar for dub. But I can do that 
if there is interest.



Not at all. Seems like an amazing tool!


Agree. Give it a shot. It does not hurt your system because the 
installer only uses /gnu (for the software) and /var/guix (for 
the database). To uninstall simply remove those dirs.

Guix never overwrites system directories.

Re: Dub, Cargo, Go, Gradle, Maven

[Pjotr Prins via Digitalmars-d]

On Thursday, 15 February 2018 at 04:11:51 UTC, Graham St Jack 
wrote:
Maybe a compromise position would be for a package management 
system to define an interface through which it can do things 
like:


* Discover what the external dependencies are,

* Provide those external dependencies, and

* Invoke a full build.

Then, any number of build systems (and deployment systems?) 
could be adapted to work with the package management system.


That is exactly what GNU Guix offers. With support for isolated 
builds, continuous integration testing, and containers thrown in, 
if you want that. People misunderstand Guix somewhat because it 
presents itself as a 'package manager' and even distribution in 
its own right. But actually it is a dependency manager that can 
run on top of any system.


I am writing a BLOG on how to use Guix for Python development 
using its package managers and even dependency injection (say a 
choice of BLAS libraries or LLVM in the case of D). When that is 
done I could do a D writeup if there is enough interest.


I am sure some people roll their eyes when I mention GNU Guix. 
But, hey, if you are an Emacs or gcc user you may be able to 
afford to pay attention to long running GNU projects.


To anticipate real criticism: there are currently two main 
issues: (1) GNU Guix runs on Linux and (2) the default requires a 
running build daemon.


About (1) since this is a libre project the focus is on Linux and 
Hurd. It is actually fairly straightforward to port Guix to other 
OS's. Nix, which shares the build daemon with Guix, runs on OSX 
and Windows.


About (2) the daemon can run unprivileged. I have written 
documents about running Guix without root access (I need it on 
HPC). It is just a little more involved.


Anyway, I don't really care who uses Guix or who uses something 
else. I expect 99.9% of people to ignore these ideas. Just to say 
I simply use it to make my own life easier. The point here is 
that I understand what it took to create Guix and it is 
non-trivial. We can reuse this functionality very easily and take 
control over the dependency graph. You get reproducible builds, 
easy mixing of LLVM versions and many other features. Fixing (1) 
above is much easier than recreating something like Guix from 
scratch. And since Guix is distribution agnostic you can use it 
on any old CentOS, Debian, Ubuntu... you name it. The only thing 
Guix uses is the *running* kernel API. Even glibc and the linked 
library loader come with Guix (and you can easily run multiple 
versions of said libraries). That is a full and deep dependency 
graph.


With Guix I do not need dub or pip or gems. It is trivially easy 
to manage dependencies. Still I can use those package managers if 
I want to. In a controlled fashion.


PS The JVM world has the advantage of being a clear and isolated 
system. Good news is that Guix supports that too and it provides 
an awesome libre bootstrap from source. If you care about the 
free and open in FOSS that is a huge selling point in a world 
that appears to increasingly bootstrap from binary blobs.


It is easy to write-off such ideas. But if you don't try it, you 
don't understand it. Similar to the D vs other language 
discussions. I am not going to say Guix is easy. Similar to the 
fact that D is not easy. But you can gradually get in and learn 
to appreciate the great engineering under the hood. That goes for 
Nix too. Guix and Nix still share the build daemon, though they 
have become completely different systems with different 
characteristics.


If you want to try Guix - I am here to support you.

Re: Being Positive

[Pjotr Prins via Digitalmars-d]

On Tuesday, 13 February 2018 at 03:15:44 UTC, bachmeier wrote:
I don't see a negative trend. It's always been negative around 
here, and I've never understood why. It's the best language 
I've used by a significant margin. D is the inverse of the Lisp 
community, which believes the Common Lisp Hyperspec was 
delivered on stone tablets.


Funny. Maybe it is a self-organising engineering culture that has 
evolved. We have a mixture of critical people here and the 
occasional nutcase. You see that in most popular FOSS projects, 
but D is pretty extreme.


The harmful part of all theses messages, apart from disgusting 
the more sensitive among us, is that I find people (say at this 
FOSDEM - btw great talk Kai) telling me that D is immature. These 
people read these threads. So they don't even try D. Being 
positive helps recruit people into trying things out on their 
own. I would not call it social engineering per se, but 
ultimately you want people to come in the door and try stuff. 
Only then will merit pay off.


I start to wonder if we just shut off and remove the forum 
history would actually improve the takeup of D. I wonder if 
project leaders would stop posting it would actually improve the 
takeup of D. Maybe we should just try that for a year. Someone I 
knew would (in the days of paper) move his inbox into the trash. 
He would say: if it is really important it will come back. A 
clean slate makes the day fresh.


My proposal: remove the forum and history completely and for a 
year only produce blogs. We still have github, bugzilla, DIPs 
etc. Plenty ways to express yourself and contribute. Project 
leaders stop posting so they can focus on the technical side of 
things.


I've even raised the issue myself. Everyone complains about 
Walter and Andrei and the lack of tools and so on, but I see a 
lot of progress. I don't really care about who isn't using D or 
why. For many years I saw the same thing in the Linux community 
yet year after year I had a computer that just worked.


Yes. Remember the days everyone was using Windows and just a few 
of us were using Linux. I do not think D will be *that* 
successful, but it has enough momentum to keep going. It is a 
solid investment in my book.

Re: Which language futures make D overcompicated?

[Pjotr Prins via Digitalmars-d]

On Monday, 12 February 2018 at 02:31:38 UTC, Jonathan M Davis 
wrote:
On Sunday, February 11, 2018 19:01:09 Jonathan M Davis via 
Digitalmars-d wrote:
As with too much around here, a big part of the issue is 
ultimately man power. Even if we could all agree on exactly 
how D's build and package management situation should be 
solved, actually get the work done is a huge problem.


On that note, I feel that I really should thank Sonke and those 
few that have helped him write dub. As much as I think that 
some aspects of dub need to be redesigned, at least they 
actually went and did something and managed to get it to take 
off enough that there are quite a few D libraries available 
using dub. So, while the solution may not be what we want, at 
least we have a solution.


Absolutely. Dub gets criticism because it is used which is an 
indicator of a successful piece of work. Kudos for anyone who 
pulls that off. Now we just find it is hard to do this well.


As someone involved with software distribution and deployment in 
production systems, my suggestion is to limit the scope of the 
package manager. Best have to do it little, but do it well and 
make most of existing solutions. The goal should really be 
package discovery and making it easy for beginners (autotools and 
configure does not do today, though C gets away with it). 
Thereafter comes a point you have to hand over the deployment 
issue. I strongly suggest not to make it complicated and not to 
try to create a homogeneous development system for all targets. 
I'll write up how I manage my development and deployment some 
time later this year, it may or may not be a good example ;)

Re: Which language futures make D overcompicated?

[Pjotr Prins via Digitalmars-d]

Dub is getting some flak here. This is unsurprising because it is 
really hard to write a good package manager and build system. I 
use a lot of languages and not one has a satisfactory package 
manager. Mostly they try to do too much and get in the way or 
they do too little and people complain (I prefer the second 
option). And when there are 100+ dependencies, like with Go and 
Node, it just becomes impossible to say anything about the state 
of the system (security, anyone?).


Package management is mostly dependency management. This I handle 
with GNU Guix (and Nix) package managers. They are great at that. 
This also leaves people to choose any old build system. Inside 
GNU Guix the build system is consistent, which is really nice. 
I'll write a blog some time this year.


What you really want is to be able to discover packages (i.e., a 
website such as Dub provides), pull them into your tree (which is 
just a path and can be handled by git submodules, though I don't 
like those much either), and when you distribute: add them to 
Guix or Nix and provide those packages with build system and as 
binary deployments to others. These package managers give control 
over the full dependency graph, including shared libraries all 
the way down to glibc.


I am not posting this to plug these systems per se. Just saying 
that writing a generic package manager is hard and is better left 
to systems that solve handling the full dependency graph 
correctly. Personally, I am happy very happy with what Guix gives 
me. Can't think of a better way. I have no reason to use dub.

Re: How do you use D?

[Pjotr Prins via Digitalmars-d]

On Wednesday, 3 January 2018 at 18:36:29 UTC, Ola Fosheim Grøstad 
wrote:
Then you have this all the psychological effect that if people 
have invested significant time, resources and/or emotion into 
something then they will defend it and refuse to see flaws even 
when faced with massive evidence against it. So the hype will 
be sustained by a vocal set of believers if you have reached  a 
large enough audience with your messaging before the product is 
launched…?


Aye.

Then it tapers off in a long tail… or the believers will make 
it work somehow, at least good enough to not be a lot worse 
than the alternatives.


I am thinking of Python here. I have to work in Python and there 
is no love lost.


Regarding hype. I think it is fairly easy to create a new 
language these days - thanks to LLVM and JVM targets. New 
languages pop up every other week it appears. Getting it right, 
however, takes a lot of time. D proves how much it takes to 
create a great (complex) language and deal with most corner 
cases. Writing a performing compiler (run time and compile time) 
is no mean feat.


docs. I just disagree with the aim of trying to make D a hyped 
language.


Yes, that is a bit late, I think. You would have to launch D3 
or something to get a hype effect (at least in the west).


I think D is too powerful/complicated to become a target for 
millions. The irony does not escape me, with many C++/JVM 
programmers out there, that D is a great replacement for C++ and 
many JVM languages. I did a stretch of Scala and I think D is the 
superior language, even if it misses out on some nifty Scala 
features. But that does not mean people will take to D in droves. 
Scala is bigger.


Anyway, my opinions do not matter that much. Suffice to say I 
enjoy D and I think it is perfect for our large data processing 
projects.


A language like GNU Guile has only a few developers - and they 
do great work.


But is Guile used much outside GNU affiliated projects?


No. Not that I am aware. Still, it is an amazing effort by a 
small group of people. I am partial to organizing a Guile/Guix 
day. Feel free to join in! 
https://libreplanet.org/wiki/Group:Guix/FOSDEM2018.


Pj.

Re: How do you use D?

[Pjotr Prins via Digitalmars-d]

On Wednesday, 3 January 2018 at 10:29:05 UTC, Ola Fosheim Grøstad 
wrote:

On Wednesday, 3 January 2018 at 09:56:48 UTC, Pjotr Prins wrote:
average ones. And D must be there. Similar to the Haskell and 
Lisp communities we have the luxury of dealing with the best 
programmers out there.


This attitude is toxic, and it isn't true either.


We differ in opinion here.

Good programmers aren't stuck on any single language and will 
pick the tool best suited for the job at hand.  Good 
programmers are also good at picking up new languages.


Very true. Some languages are harder to learn and apply then 
others. Few C++ programmers make great Lisp or Haskell 
programmers.


Hype leads to critical mass, which leads to higher productivity 
because you get better tooling, better documentation (including 
stack overflow), better libraries and better portability.


I don't disagree. I am reacting to other messages where people 
assert that we need to improve this and that for the sake of 
popularity. Maybe it is toxic not to care too much about what 
other people want/need and perhaps I am wrong. But I don't think 
D will become a hyped language, so we may as well stop wanting to 
be one. D is a language for software engineers - and they come if 
they need it. I remember a Google engineer telling me that he was 
tired of people bringing up D every time. That was 10 years ago. 
D has had every chance to become a hype ;)


Erlang has been a non-hype language for a long time. Now the 
success of whatsapp made it a lot more interesting to startups 
and therefore it is growing. Even so, I don't think it will ever 
become a hype. If you program in Erlang you can appreciate why. 
What is it that makes a hyped language?


That should not stop us from answering questions and writing 
docs. I just disagree with the aim of trying to make D a hyped 
language.


The only time where it is an advantage to be small is when your 
language design is changing. Once the language design is stable 
there is only disadvantages in not having critical mass.


A language like GNU Guile has only a few developers - and they do 
great work.


D and its community are not small in my book. Large enough not to 
be endangered and still keep moving forward. Hard but soft. About 
right.

Re: How do you use D?

[Pjotr Prins via Digitalmars-d]

How do you use D?


I write code for a living.

We use D for writing the next generation critical large data 
software. Sequencing centers churn out TBs of data per day and 
writing code in Python does not cut it. Even JVM tools are 
problematic when it comes to raw performance. Sambamba, written 
in D, has been doing heavy lifting since 2014 and is running 
every second of the day somewhere on an HPC diagnosing cancer.


Did you introduce D to your work place? How? What challenges 
did you face?


Not that many as we make up the rules. Great programmers tend to 
like D once they grok it.
Writing idiomatic D takes time though. I have written significant 
code in a great number of languages, including Ruby, Python, C++, 
Perl (ugh), Lisp, Elixir, Erlang, Scala... I am in a position to 
state what I like. Currently I favor Ruby for the quick and 
dirty, Elixir for web programming and D for data processing and 
raw speed. It is the fastest car in my garage. It would be C++ if 
I had no D - and I am very glad I don't have to write new code in 
C++. There are reasons I still use other languages. Ruby feels 
just slightly more productive and Elixir has some great features 
too for a functional programming language. I have absolutely no 
incentive to program in Go or Rust though I sometimes have to 
read such code. I think Go is a royal pain.



What is you D setup at work, which compiler, which IDE?


ldc and emacs. GNU Guix handles all dependencies.


And any other fun facts you may want to share :)


Started late programming 70s after a stretch playing chess. Been 
coding ever since. My first encounters with Walter were on 
Compuserve when I was using Zortech and Symantec C++ compilers. 
Obviously I am glad we moved forward, tooling-wise.


On Sunday, 6 August 2017 at 05:39:36 UTC, Laeeth Isharc wrote:
similar with programming language choices and such.  Its way 
better to appeal to people who make up their own mind and bear 
the consequences then to those who have to cover their behinds 
by getting the right ticks in the boxes because the are never 
going to be earlier adopters except through some unfortunate 
accident - because you also don't want such people as early 
adopters!


I think that is very true. I can understand why the people 
involved in D want it to be popular - to become famous, rich, or 
if only to convince those at work. But I think it is fine to 
target thousands of great programmers, rather than millions of 
average ones. And D must be there. Similar to the Haskell and 
Lisp communities we have the luxury of dealing with the best 
programmers out there.


Hyped languages are for suckers.

Even so, if you are a D programmer and your work environment does 
not allow you to use D, 'popularizing' D is not going to help 
that (how do you popularize a powerful language?). Grind your 
teeth and write in whatever the job dictates (I do that too), but 
sneak in your best work in D without telling anyone. There are 
always opportunities. Don't complain. Move on. That is my advice.


I predict D has enough momentum to stay and be a better 
alternative to C/C++/JVM. Which is the main thing. Even when 
Walter and Andrei would drop out, for whatever reason, D will 
continue. There are some language features I would like, but to 
be honest I can live without them.

Re: What don't you switch to GitHub issues

[Pjotr Prins via Digitalmars-d]

On Monday, 1 January 2018 at 02:02:03 UTC, rjframe wrote:

That's probably not the best method of effecting change.


It killed off the discussion nicely, indeed.

I am just going to share my thoughts a little. Github, in my 
opinion, is hype and even though I depend on it today, I am 
trying to decrease that dependency. We should build a world that 
is not dependent on single companies. I am not downplaying what 
github has done for us (I am one of the early users) - but they 
have just become a little too important for free software to be 
comfortable. The github issue tracker is wanting anyway.


D is a great language. I just spent 6 months in C++ and the last 
month worked on a D multi-threaded project again. I'll blog about 
this soon, but the short of it is that I am very grateful to 
Walter, Andrei, Kai, Ian, Johan and others for creating a 
language that fits our needs so well! D software is doing 
critical work around the world every second. D is probably not a 
language for the hype community - let them have Go and Rust. I 
honestly don't care. And D should not care. Great programmers 
gyrate to powerful languages and toolboxes. I love I can read the 
source code of Phobos and understand it. I love I get low level 
access to stack variables. I love I can manipulate the heap in 
any way I want. I love we can target GPU and KNL. I love we have 
Maybe even though it is called Nullable...


A great programmer can handle D fine. As it is. Let's not try to 
be the next hype. Let's keep writing great software.


Pj.

Re: What is going on with the ubuntu/debian debacle ?

[Pjotr Prins via Digitalmars-d]

I have created a relocatable GNU Guix 64-bits binary of ldc 1.1.0 
(just released) that will install on any Linux distribution.


  LDC - the LLVM D compiler (1.1.0):
based on DMD v2.071.2 and LLVM 3.7.1
built with LDC - the LLVM D compiler (0.17.1)
Default target: x86_64-unknown-linux-gnu

ldc can be installed and run in a HOME directory without root
privileges by simply unpacking the tarball from


http://biogems.info/contrib/genenetwork/pk9rkm4zvdp6pglam7s280x1x8y5rvbz-ldc-1.1.0-x86_64.tar.bz2

md5sum fe2508135eadc87fcc31027524c11ec5

and running the contained

  ./install.sh TARGETDIR.

From TARGETDIR ldc2 can compile hello.d and
also a more complex project where I had to tell it where to find
libphobos.a (which is included).

I need a few people to test drive this. Please have a go if you 
have a
few minutes because it is important we can deploy such software 
on HPC
systems. GNU Guix is great because it gives us a fully 
reproducible

build system and relocatable Guix does not require administrator
rights, nor Docker.

In a future version we will update LLVM and add dup (support for 
both already exists in Guix).

Re: What is going on with the ubuntu/debian debacle ?

[Pjotr Prins via Digitalmars-d]

On Monday, 21 November 2016 at 19:23:23 UTC, Stefan Koch wrote:

I will try to reproduce and fix the issue.


We are also working on a new GNU Guix package for ldc latest. 
More on that soon.

Re: Reproducible builds of D compilers

[Pjotr Prins via Digitalmars-d]

On Saturday, 7 May 2016 at 17:56:07 UTC, Johan Engelen wrote:
On Saturday, 7 May 2016 at 16:22:34 UTC, Vladimir Panteleev 
wrote:


https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/


Thanks for repeating the link to that blog article. I was 
reminded of it at DConf. Would be great if results from GDC and 
LDC could be added to the graphs, plus more tests!


Yes, nice read!

Re: To all DConf speakers: please upload slides!

[Pjotr Prins via Digitalmars-d-announce]

On Wednesday, 11 May 2016 at 09:17:54 UTC, Dicebot wrote:
To do the editing of HD videos we need presentation slides 
which are currently scattered over different places. It would 
help a lot to have them all in github.com/dlang/dlang.org repo 
- please submit pull requests asap!


Lightning talk slides also to be included? Mine are at 
http://biobeat.org/dconf2016.pdf

Re: Reproducible builds of D compilers

[Pjotr Prins via Digitalmars-d]

On Saturday, 7 May 2016 at 08:53:10 UTC, Thomas Mader wrote:
GNU Guix can be used as a reproducible reference build system 
where we capture the bootstrapping process nicely and test the 
builds on the build farm(s) whenever something changes.


I like the idea.
I thought about that too but would not use GNU Guix for it.
I would suggest to use Nix -> http://nixos.org/
AFAIK GNU Guix uses some parts of Nix and I think the community 
behind it is not as big.

There are also packages for dmd on Nix already.
I also was able to get the ddmd frontent version of dmd running 
on Nix.
Nix would be the perfect system to base all the testing on 
because it's very easy to distribute entire system 
configurations over multiple computers.
So once everything is setup correctly and the knowledge is 
there, it makes administering entire server farms pretty 
comfortable.


Hi Thomas! Good news, Nix and Guix can easily be used on one 
system. I am a GNU Guix person (for several reason; also used Nix 
for years), and I am glad to say that the community is growing 
rather fast. Guix is a pretty young project.


I am committed to supporting the D language on Guix (if only to 
deploy my own working environments), be great to have the same on 
Nix.

Reproducible builds of D compilers

[Pjotr Prins via Digitalmars-d]

At Dconf we had a discussion on creating reproducible builds of 
the D compilers. One thing that is required is bootstrapping the 
build. In GNU Guix we start from a working C compiler which is a 
reasonable starting point (it could have been LISP instead ;)


For D this means that even if all components of the compilers are 
written in D we should have a (chain of) compilation steps that 
can be initiated from a C or C++ compiler. This is still the case 
today, but I want to highlight this point here so we do not lose 
that facility.


GNU Guix can be used as a reproducible reference build system 
where we capture the bootstrapping process nicely and test the 
builds on the build farm(s) whenever something changes.