>
> I really wish people would stop complaining about other languages having the same features as D without giving credit. It is impossible to figure out exactly where ideas from features come from, but most features predate even C++ if being first is the main point.

Hear, hear, is it so unlikely that one footstep should fall in the footprint of another?

>
> The hard part about designing an imperative language is not the individual features, the palette is given. The hard part is turning it into beautiful whole that is greater than the sum of the parts. And that is important, but difficult (or impossible) to achieve.

This is it. Great languages (IMO) have condensed their features down to the smallest set of orthogonal features that they could manage. This makes the language easier to reason about, to share code, to maintain code, to learn, to read code, even writing it is often easier!

Right now I feel that D is growing in 'features' and corner cases beyond the point where I want to explore it's depths. It's gone from a swim in the bay into crossing the Channel. I always think about Herb Sutters Guru of the Week column and how it made me think "ugh - too many oddities to learn". I could be wrong and I hope I am.

It's quite a nice twist that the thread discussing which language is better branched into what version of English is the right one - as if such a thing is meaningful. Arguing about definitions and terminology is surely such a useless diversion.

On Thursday, 11 June 2015 at 00:27:09 UTC, Dave wrote:
>> The promise of exceptions isn't to not have to specifically handle errors in every layer
>
> Correct me if I am wrong, but aren't exceptions in D used for
> general error handling? Doesn't Phobos prefer exceptions over
> return codes?

It seems to be a controversial subject: https://github.com/D-Programming-Language/phobos/pull/1090#issuecomment-12737986

>> it's to not care about exceptions in every layer.
>
> My second job was working in the sustaining department of a large
> company. One of the most frequent cause of bugs were people not
> checking errors. The fix was almost always handle the error at
> its source and log or signal a message to some IO informing the
> user. Users tend to prefer messages over complete meltdowns. Too
> many avoidable outages and crashes came by my desk due to this
> attitude. Very few domains/cases require hard fails.

Exceptions are not meant to force handling errors at he source. If you want to force handling errors at the source they should be part of the return type. I'm not talking about C style return-error-code-and-write-the-actual-result-into-a-variable-passed-by-reference - functional languages like Haskell, Scala and Rust have shown that monadic sum types of result/error are both safe(don't allow you to access the returned value unless you do it in a path that makes sure there wasn't an error, or convert the error into an exception) and easy to use(adds very little syntactic overhead for the good path, and the bad path code is simpler than in exception handling)

Exceptions are not "hard fails". You don't have to crash the entire program - just fail the action the user was trying to do and display a nice error message with whatever information you can and want to provide to the user. Even if you don't handle them, they provide information useful for debugging.

>> I don't want to pass the annotation in each and every intermediate layer
>
> Seems like an odd comment to have on the forum of a language that
> frequently has functions in the standard library annotated like
> this:
> pure nothrow @nogc @safe real abs(Num)(Num y)

Just because I use the language doesn't mean I have to like every single one of it's features...

>> I've programmed enough Java to know how harmful nothrow-by-default is.
>
> I disagree one this. Lets agree to disagree.

I agree to disagree

>> It doesn't really guarantee the functions not annotated as throwing won't > crash
>
> Combined with other guarantees (such as immutability, thread
> local storage, safe memory management, side-effect free code, no
> recursion, etc), you can make a reasonable guarantee about the
> safety of your code.

And a superhero cape, combined with an airplane, airplane fuel and flight school, allow you to fly in the air.

It is the other restrictions(without getting into a discussion about each and every restriction in the list) that make the code safer - nothrow doesn't really contribute IMO.

>> If it's an error that the caller needs to know about - make it part of the return type. If it doesn't need to know about it - throw an exception and let someone up the line handle it.
>
> I don't agree with this. Too much to worry about. Impractical to
> maintain both paradigms. What errors don't you need to know about?

Scala and Rust seem to maintain both paradigms just fine. It's actually beneficial to have both - you have to acknowledge return-type-based exceptions, and you can always bypass them by turning them to exceptions, which are good for logging and debugging. If exception handling is enforced, they can only by bypassed by converting them to errors or crashes, which are much less nice than exceptions when it comes to debugging, logging and cleanup.

If I have to be explicit about not handling an error somewhere, I prefer the "this exact thing here can return an error, I assume it won't, but if it does you'll get an exception so it can be debugged" approach over the "not that I care, but something, somewhere down that path might throw" approach.

>> handle it or ignore it.
>
> The process I mentioned would not prevent this in anyway. Just
> inform others of the decision you made that may have adverse
> effects on the stability of their code.

Writing code that acknowledges that this code can fail due to an exception somewhere else does not count as ignoring it.

On Thursday, 11 June 2015 at 11:40:55 UTC, Abdulhaq wrote:
> Hear, hear, is it so unlikely that one footstep should fall in the footprint of another?

We all stand on the shoulders of giants, etc.

> This is it. Great languages (IMO) have condensed their features down to the smallest set of orthogonal features that they could manage. This makes the language easier to reason about, to share code, to maintain code, to learn, to read code, even writing it is often easier!
>
> Right now I feel that D is growing in 'features' and corner cases beyond the point where I want to explore it's depths. It's gone from a swim in the bay into crossing the Channel. I always think about Herb Sutters Guru of the Week column and how it made me think "ugh - too many oddities to learn". I could be wrong and I hope I am.

Aye. I think what I totally dislike about C++ is that I cannot hold the whole language in my head. It is unthinkable that I could just type in a C++ program using the full feature set and compile it with no complaints from the compiler and quite a bit of head-scratching to figure out why it won't take code that looks sensible.

Corner cases is a major reason for increased cognitive load. Even javascript gives me that feeling, caused by the odd weird non-intuitive flaws that makes such a simple language not so simple after all.

We'll see what happens when DMD is translated to D and refactored. Maybe someone creates an experimental D3 from it to see if it can be made a bit more orthogonal. I think that could be an important move.

> It's quite a nice twist that the thread discussing which language is better branched into what version of English is the right one - as if such a thing is meaningful.

As a norwegian I can't make up my mind as to whether I should write "color" or "colour". I suspect it will be taken as some kind of political statement. Hey, I am neutral! I use "color" in source code and "colour" in writing. :)

On Thursday, 11 June 2015 at 11:37:21 UTC, Bruno Medeiros wrote:
> On 10/06/2015 12:38, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> I think Rust has an advantage over Go in the name Mozilla alone, they
>> are more idealistic than Google.
>
> Agreed. In concrete terms, Mozilla is a non-profit, whereas Google is not. Google can easily drop (or reduce) support for Go if it doesn't serve whatever business goal they want. Or alternatively they might not be interested in evolving Go (or Go's toolchain) in directions that are useful for other people, but have little value for their business or technical goals.

I'm afraid, Mozilla is the same: picks a group of people to prioritize and ignores others.

On Thursday, 11 June 2015 at 11:37:21 UTC, Bruno Medeiros wrote:
> On 10/06/2015 12:38, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> I think Rust has an advantage over Go in the name Mozilla alone, they
>> are more idealistic than Google.
>
> Agreed. In concrete terms, Mozilla is a non-profit, whereas Google is not. Google can easily drop (or reduce) support for Go if it doesn't serve whatever business goal they want. Or alternatively they might not be interested in evolving Go (or Go's toolchain) in directions that are useful for other people, but have little value for their business or technical goals.

And Google will be right in abandoning an unsuccessful project. Supporting such project wouldn't benefit anyone and reusing resources in other promising projects is to the benefit of everyone.

On Thursday, 11 June 2015 at 12:11:49 UTC, Ola Fosheim Grøstad wrote:
>
>
> As a norwegian I can't make up my mind as to whether I should write "color" or "colour". I suspect it will be taken as some kind of political statement. Hey, I am neutral! I use "color" in source code and "colour" in writing. :)

As an Englishman I used to rail against the USA-ification of the language but now I've learnt to bite the bullet and actually follow the same rule as yourself. Saves a lot of indigestion :-)

On Thursday, 11 June 2015 at 12:15:21 UTC, Kagamin wrote:
> On Thursday, 11 June 2015 at 11:37:21 UTC, Bruno Medeiros wrote:
>> On 10/06/2015 12:38, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>> I think Rust has an advantage over Go in the name Mozilla alone, they
>>> are more idealistic than Google.
>>
>> Agreed. In concrete terms, Mozilla is a non-profit, whereas Google is not. Google can easily drop (or reduce) support for Go if it doesn't serve whatever business goal they want. Or alternatively they might not be interested in evolving Go (or Go's toolchain) in directions that are useful for other people, but have little value for their business or technical goals.
>
> I'm afraid, Mozilla is the same: picks a group of people to prioritize and ignores others.

You will live to see splinter groups. Go++, Open Rust etc. It's always the same, languages that follow a narrow path will p**s off people enough for them to role their own.

D is really unique in the sense that it's open enough for people not to feel that they have to role their own. D also has enough features to satisfy many different users, although - and this is often forgotten - you don't _have_ to use them all. People like Go and Rust, because it tells them exactly what to do. D doesn't, they have to think for themselves, and a lot of people hate that, which is sad, because having loads of things to choose from makes you think more about your code and software design in general and it makes you a better programmer/coder/architect.

On Thursday, 11 June 2015 at 12:21:30 UTC, Kagamin wrote:
> On Thursday, 11 June 2015 at 11:37:21 UTC, Bruno Medeiros wrote:
>> On 10/06/2015 12:38, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>> I think Rust has an advantage over Go in the name Mozilla alone, they
>>> are more idealistic than Google.
>>
>> Agreed. In concrete terms, Mozilla is a non-profit, whereas Google is not. Google can easily drop (or reduce) support for Go if it doesn't serve whatever business goal they want. Or alternatively they might not be interested in evolving Go (or Go's toolchain) in directions that are useful for other people, but have little value for their business or technical goals.
>
> And Google will be right in abandoning an unsuccessful project.



> Supporting such project wouldn't benefit anyone and reusing resources in other promising projects is to the benefit of everyone.

Thinking as an economist and as a businessman that simply isn't true.  Whether a project fits with their own business goals is one thing; whether their business decisions might leave me stranded high and dry is another.  Now, a state of affairs where they are forced to support projects they wish to abandon would hardly be consistent with dynamic economic efficiency - it's not time consistent for one thing.  But in my experience one is foolish to create long-lived specific capital (a code base) whose value is complementary to services provided by another organisation without considering the incentives and habitual behaviour of this organisation.

On Thursday, 11 June 2015 at 12:21:30 UTC, Kagamin wrote:
> And Google will be right in abandoning an unsuccessful project. Supporting such project wouldn't benefit anyone and reusing resources in other promising projects is to the benefit of everyone.

Actually, it is a problem that makes people reluctant to use Google technologies and that overall harms the Google eco-system way beyond individual projects.

Dart recently announced that they are now on github. In the comment field on that announcement people complained about how their workplaces choose Typescript over it, despite Dart being more suitable. They think Google will abandon it. In other news Google claimed to have 1 million lines of internal Dart code and use it for their ad sales services. So apparently they would like to keep the eco system alive.

People are not abandoning Dart because shows any signs of being a dead or a bad language, they do it because they don't trust Google.

> D is really unique in the sense that it's open enough for people not to feel that they have to role their own. D also has enough features to satisfy many different users, although - and this is often forgotten - you don't _have_ to use them all. People like Go and Rust, because it tells them exactly what to do. D doesn't, they have to think for themselves, and a lot of people hate that, which is sad, because having loads of things to choose from makes you think more about your code and software design in general and it makes you a better programmer/coder/architect.

Thinking like that is fine when you work on your own, but when you're in a large team and working on a large code base the prospect of trying to grok a dozen different coding approaches using different feature sets of some uber language is entirely unappealing and best avoided.