On Friday, 26 February 2016 at 11:01:46 UTC, Walter Bright wrote:
On 2/26/2016 1:47 AM, Radu wrote:
Please don't get me wrong, we all apreciate what you offered
to the D community,
but all these legal arguments are strongly tied to you, and
less so to the
community.
Didn't Google get hung out to dry over 6 lines of Java code or
something like that? And I don't know how long you've been
around here, but we DID have precisely these sorts of problems
during the Phobos/Tango rift. Ignoring licensing issues can
have ugly consequences.
I'm around here since 2004, not as vocal as I'm now, but yes, I
remember those ugly times.
Due diligence is mandatory when dealing with software license,
agreed, but we can't extrapolate your experience re. the backend
with whatever is used in LDC or any other compiler. I'm sure in
this regard LDC is not at peril.
Your LLVM license nit pick is hilarious, you can't do that
when the "oficial" D
compiler has a non-liberal licensed backend, you just can't.
That's not under my control, and is one of the reasons why D
gravitated towards the Boost license for everything we could.
Yes, agreed, boost FTW, but still doesn't solve the backend issue.
But setting things aside, we all need to acknowledge that the
current setup is
not fair to motivated and proven third party compilers, their
contributors, and
their users.
I don't see anything unfair. gdc, ldc, and dmd are each as good
as their respective teams make them.
The lack of fairness comes from the way the ecosystem is setup,
you have the reference compiler released, then everybody needs to
catch up with it. Why not have others be part of the official
release? This will undoubtedly increase the quality of the
frontend and the glue layer, and probably the runtime, just
because they will be tested on more architectures each release.
No matter how you put it, both LDC and GDC are limited in
manpower, and also caught in the merge game with mainline. This
is a bottle neck if they need to attract more talent. Right of
the bat you need to do a lot of grunt work handling different
repos, each at their own revision, plus all the knowledge about
build env and testing env.
The D ecosistem must create and foster a friendly environment
to anyone wanting
to have a good compiler that is current with the
language/runtime/phobos
developments.
And that's what we do. It's why we have 3 major compilers.
See above, just having 3 compilers (could be 5 for the matter),
it's not enough. We will be better with just one that works
great, but if that is not possible, at least give me the option
to use the latest and greatest D on my Linux embedded ARM boards.