Thoughts on replacement languages (Reddit + D)

Paulo Pinto via Digitalmars-d digitalmars-d at puremagic.com
Sun Jan 11 07:08:13 PST 2015


On Sunday, 11 January 2015 at 14:10:56 UTC, ponce wrote:
> On Sunday, 11 January 2015 at 13:37:33 UTC, Ola Fosheim Grøstad 
> wrote:
>> On Sunday, 11 January 2015 at 12:57:17 UTC, MattCoder wrote:
>>> Since I'm relative new here, I want know from you agree with 
>>> this statement:
>>>
>>> "
>>> [–]clay_davis_sheeit 4 points 17 hours ago*
>>>
>>> get real. D is more dead now than it was a year ago. if you 
>>> won't accept repo counts, look at how many people attended D 
>>> con vs Gophercon
>>> "
>>
>> "more dead" is a very subjective term.
>>
>> It is "more dead" in the sense that you got @nogc and there 
>> was a sense of movement towards getting to a workable memory 
>> model, but since then nothing has happend. One step forward, 
>> then stagnation.
>>
>> The Rust team have announced that they are moving towards a 
>> non-breaking stability situation within 6 weeks. And they have 
>> a working memory model.
>>
>> Andrei and Walter need to stop focusing on details for a 
>> moment and focus more on presenting "a great plan" within 2 
>> months. Meaning stating goals and plans which gives D a 
>> direction that developers want and can believe in.
>>
>> If no clear statements on where D is heading appears in the 
>> near future... Well, then I am pretty sure that many of those 
>> who prefer D will give Rust a spin when Rust hits 1.0, out of 
>> boredom.
>>
>> Rust is not complete feature wise, but a working memory model 
>> and stability is more important than having single inheritance 
>> and other convenience features...
>>
>> So D is not dead, but is currently in a position where it can 
>> be hit by both Go and Rust. The space between Rust (system 
>> programming) and Go (server programming) is very tiny.
>
> The problem with Rust and Go is that they only deliver in 
> theory, while D kicks some asses in practice. How?
>
> Eg: at this very moment, D is more stable than Rust, ground 
> truth.
>
> D has backends for GCC/LLVM/custom, Go has backends for GCC / 
> Plan9, Rust only for LLVM. None of Rust+Go can link with 
> binaries produced by eg. the Microsoft compiler. None of them 
> has Visual Studio integration with debugging support and that 
> is pretty important for native and enterprise programmers.
>
> Go is actively behind the times by preventing shared libraries 
> and discouraging exceptions, let alone generics. None of the 
> C++ programmers I know give Go any credit, cause it would make 
> their work more difficult, and it's already pretty difficult.
>
> Despite efforts, Rust don't get syntax right. They will enjoy 
> huge amount of complaining as soon as people actually use the 
> language, only to discover it is not fun enough and fun is more 
> important than "memory safety without GC". Looks like it 
> inherited its boringness from Ocaml.
>
> I don't buy in the Rust team stability guarantees, you can't go 
> from pondering about removing "box" this very week (the syntax 
> is from this year) then promising stability forever starting 
> next month. But for some reason everything they say has a ring 
> of truth, because it's Mozilla they only do Good Things right?
>
> They will come to the same model as D, minimizing code breakage 
> but do it anyway, because it's way more practical. And as soon 
> as Servo is interrupted because of internal politics at Mozilla 
> or rebudgeting (ie. very high probability), Rust will be halted 
> in a heartbeat since loosing its purpose. Ever noticed the Rust 
> original designer jumped off ship long ago?
>
> That won't happen with D, whatever the ratio of github projects 
> in the fashion industry.


I am known to complain about some of the Go missing features.

However I am closer to use Go than D at work alongside .NET and 
JVM.

Why? Because of Docker. Now with big names adopting Docker, our 
enterprise
customers are looking into it for cloud deployments.

D really needs a some kind of killer application/framework.

--
Paulo


More information about the Digitalmars-d mailing list