On Friday, 16 June 2017 at 10:12:06 UTC, Wulfklaue wrote:
On Friday, 16 June 2017 at 06:58:57 UTC, Jacob Carlborg wrote:
DVM [1] is doing some of this.
[1] https://github.com/jacob-carlborg/dvm
Might it not be better when some of this is actually part of D?
There is an official D installer for Posix systems that can
handle multiple compilers and all versions quite well.
IIRC does dvm only support DMD?
- Multi-version support
- Integrated all the tools so editors know/can rely on them. I
have seen this topic a few times reading here.
I think you are just complaining about Windows. Everything is
nicely packaged under Linux, Posix and OSX.
- Editor support like half working in a lot of cases
The beauty of D is that you don't need a fancy editor.
- ...
There are always tools out there to "fix" some issues with D
but Mike does have a point in stating that everything feels
fragmented.
/++
DMD / LDC are totally different installations. LDC requiring
different setup.
Really?
curl i.dlang.io | bash -s dmd
curl i.dlang.io | bash -s dmd-2.072.2
curl i.dlang.io | bash -s dmd-newCTFE
curl i.dlang.io | bash -s dmd-nightly
curl i.dlang.io | bash -s ldc
curl i.dlang.io | bash -s ldc-beta
curl i.dlang.io | bash -s ldc-1.1.0
curl i.dlang.io | bash -s gdc
LDC is frankly the default if you need real performance but the
way its developed / published / talked about, its a side
project not a main part of D. And because of that LDC feels
like it always needs to cache-up to D mainline.
Are there any features between 2.073.2 (latest LDC beta) and
2.074.1 that you actually miss?
Ifs ironic that i needed to use:
dub --compiler=C:\D2\bin\ldc2.exe
To get ldc to work...
--compiler=ldc2 works very well for me.
If i take a look at Rust ... RustUp great installer, multi
platform support, great cross compiling support ( still some
issue with dependencies ). Go has the same great cross platform
compile support. But D it feels like a struggle to figure out.
Why not publishing Dmd and LDC together as one package, one
installation, one version.
Because the top contributors to DMD are unfamiliar with the LDC
codebase. However, there are ongoing efforts to make the frontend
accessible as a library.
/++
Why is dcd, dfmt, dscanner, not part of the base installation
of D???
Because there is a very easy way to fetch & build them since DUB
is part of the release:
dub fetch dscanner
dub build dscanner
There is even a DUB API that tools can use. Too complicated?
Webfreak wrote workspace-d and is now writing serve-d to
combine code-d and the rest. But its again a side project. Its
odd there is no default language server protocol for D and it
needs a 3th party developer to implement it and then maintain
it outside of D again.
So if webfreak gets too busy with life, a breaking change
happens in D, there goes the support. Like with many 3th party
plugins ...
Don't forget that D is an open source project driven by
volunteers.
How about file watching, i know there is a D plugin that
monitors your directory and allows for recompiling ( most
languages have a feature like this ) but again, its 3th party
not part of D mainline, despite it being darn handy.
Because there's only so much that can be in a standard library.
It's way to thick imho anyways. What's wrong with using a DUB
package?
If it is that common to your work, you can add the project to you
D include directory.
D is indeed way too fragmented. Clearly a lot of good
developers but the way its handled, it feels like DMD and
Phobos are the only focus. And all the rest is side or not
integrated. This is just my feeling. And when resources are
split like this, it is indeed much more difficult for new users
to get going.
Yes because tools come and go whereas a standard library or a
package manager stays. With the limited volunteers time there's
only so much that can be done.
And in your free time, you usually work on problems that are
interesting to you?
