On 29/03/18 14:03, Maksim Fomin wrote:
> On Thursday, 29 March 2018 at 09:45:04 UTC, Shachar Shemesh wrote:
>>
>> Not so long as destructors don't reliably run.
>>
>> $ rdmd test.d
>> A(1) constructed
>> A(2) constructed
>> A(1) destructed
>> Caught: Constructor failed
>>
>> https://issues.dlang.org/show_bug.cgi?id=14246
> 
> Good catch. This is a variant of bug reported 5 years ago. The funny part of this bug is that the fix was reverted ... because of excessive code breakage.
> 
> I like D pretty much and wish to use it in serious code, but I cannot tolerate such sort of things.

I don't think the fix was reverted because fixing the bug breaks code. I think the fix was reverted because *it* broke code.

The fix made way too many assumptions that were simply not universally true. For example, it would not work with structs with @disable init or @disable this().

So, yes, the way D is built it is not easy to properly fix it. That does not mean it shouldn't be fixed.

Shachar

On Thursday, 29 March 2018 at 03:57:05 UTC, Arun Chandrasekaran wrote:
> On Tuesday, 27 March 2018 at 23:23:10 UTC, Timothee Cour wrote:

> This is deterministic destruction and not RAII. Resource is never *acquired* here. Lack of default constructors for struct in D makes it impossible to achieve the RAII as in C++.

So what else is missing for D to achieve RAII as in C++ ?
And is deterministic destruction only available for structs, what about classes

On Friday, 10 April 2015 at 18:42:20 UTC, Timothee Cour wrote:
> Nim looks very promising.
> Is there any comprehensive comparison against D somewhere (if possible
> recent) ?

Nim is way more expressive than D afaik. Consider the following imaginary function:

proc fn[A : int | float; N; B : seq[A] | DoublyLinkedList[A] | array[N, A] | set[A]](x: B) : int =
    return x.len() + 10

This function takes an argument of type B, which is can be either a vector or forward-list or array of (array's length is N, which can be of any numeric type) or a set of A. A can be either int or float only.

Emulating those inline constraints in D would be cumbersome.

@helxi I invite you to contribute PR's to https://github.com/timotheecour/D_vs_nim/ where I discuss feature parity and how to translate concepts from D to nim wherever it makes sense


On Fri, Apr 13, 2018 at 4:12 PM, helxi via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 10 April 2015 at 18:42:20 UTC, Timothee Cour wrote:
>>
>> Nim looks very promising.
>> Is there any comprehensive comparison against D somewhere (if possible
>> recent) ?
>
>
> Nim is way more expressive than D afaik. Consider the following imaginary function:
>
> proc fn[A : int | float; N; B : seq[A] | DoublyLinkedList[A] | array[N, A] |
> set[A]](x: B) : int =
>     return x.len() + 10
>
> This function takes an argument of type B, which is can be either a vector or forward-list or array of (array's length is N, which can be of any numeric type) or a set of A. A can be either int or float only.
>
> Emulating those inline constraints in D would be cumbersome.

On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote:
> I've created a git repo https://github.com/timotheecour/D_vs_nim/ with the goal: up to date and objective comparison of features between D and nim, and 1:1 map of features, tools, idioms and libraries to help D users learn nim and vice versa.

I just recently came across Andrei's comparison of D, Rust, and Go [1].  I'd love to see that updated and hear his take on Nim.

I don't have experience with Nim yet, but from what I've read it seems to match D's 10x "easier to interface with C and C++".  Other possible 10x items are the GC, macro system, and the development community being able to focus their resources at a higher level (no linker, competing compilers, headaches targeting arm64, etc. etc.).

[1] https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why

On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:
> P.S., the example on the language's frontpage is cool!
>
> http://nim-lang.org/
>
> Why should I be excited?
> Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code. Working on disjoint data means no locking is required and yet data races are impossible:

I believe Rust's rayon [1] can do this too...

[1] https://github.com/rayon-rs/rayon

On Thu, 2018-04-19 at 16:50 +0000, Per Nordlöw via Digitalmars-d wrote:
> On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:
> > P.S., the example on the language's frontpage is cool!
> > 
> > http://nim-lang.org/
> > 
> > Why should I be excited?
> > Nim is the only language that leverages automated proof
> > technology to perform a disjoint check for your parallel code.
> > Working on disjoint data means no locking is required and yet
> > data races are impossible:
> 
> I believe Rust's rayon [1] can do this too...
> 
> [1] https://github.com/rayon-rs/rayon

Has anyone got Pony on their list of interesting languages?

-- 
Russel.
==========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Friday, 20 April 2018 at 11:07:30 UTC, Russel Winder wrote:
> On Thu, 2018-04-19 at 16:50 +0000, Per Nordlöw via Digitalmars-d wrote:
>> On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote:
>> > P.S., the example on the language's frontpage is cool!
>> > 
>> > http://nim-lang.org/
>> > 
>> > Why should I be excited?
>> > Nim is the only language that leverages automated proof
>> > technology to perform a disjoint check for your parallel code.
>> > Working on disjoint data means no locking is required and yet
>> > data races are impossible:
>> 
>> I believe Rust's rayon [1] can do this too...
>> 
>> [1] https://github.com/rayon-rs/rayon
>
> Has anyone got Pony on their list of interesting languages?

Yep, I have. To bad about no curly braces, though.

On Friday, 20 April 2018 at 11:07:30 UTC, Russel Winder wrote:
>
> Has anyone got Pony on their list of interesting languages?

I had spent some time looking over the reference capabilities [1], but I'm not sure I have the time to actually program in the language. The isolated type seemed like the most interesting take-away. I think someone on the D forums had been trying to get something similar.

[1] https://tutorial.ponylang.org/capabilities/reference-capabilities.html

As for me, I find the Nim programming language interesting. However I dislike syntax a bit, in some cases Python+Pascal syntax style of Nim looks very ugly in my opinion. Also I strongly against relying on C compiler for code generation, knowing how slow it can be. Obviously it was easy for them to use C as a pure-text backend, but I think these days LLVM should be used instead.