On 1/12/2015 3:02 AM, Tobias Pankrath wrote:
> As far as I understand is, it requires each component to settle on the same
> discriminated union that packs the error and result, which he calles Result but
> is usually Choice in F#.
>
> Now in D we use the opDot to chain components, which works since we have UFCS.
> In F# there a simply three different opDots: >>, >>= and >=> which take care of
> the adaption.

Or we could just use exceptions, which require none of that.

On 1/12/2015 2:04 AM, Iain Buclaw via Digitalmars-d wrote:
> Up to this point, I you reminded me of a talk by Joe Armstrong
> (inventor of Erlang)
>
> https://www.youtube.com/watch?v=lKXe3HUG2l4


I've found another problem with Windows Moviemaker, it can read, but cannot write, movies larger than 4Gb. Looks like some sort of internal 32 bit overflow.

I am once again a unique snowflake, because in googling around I can find nobody else with this issue.

(I have many 6Gb video files, as they come from my old 6 hour VHS tapes made in the 80's. I decided to digitize them and throw the tapes away. VHS tapes are only supposed to last 10 years, I am frankly amazed that they are in good shape after 30. My video capture device generates about 1Gb per hour of video.)

On Monday, 12 January 2015 at 11:09:01 UTC, Walter Bright wrote:
> On 1/12/2015 3:02 AM, Tobias Pankrath wrote:
>> As far as I understand is, it requires each component to settle on the same
>> discriminated union that packs the error and result, which he calles Result but
>> is usually Choice in F#.
>>
>> Now in D we use the opDot to chain components, which works since we have UFCS.
>> In F# there a simply three different opDots: >>, >>= and >=> which take care of
>> the adaption.
>
> Or we could just use exceptions, which require none of that.

Well, yes. I don't think though, that either exception or "railway" requires more boilerplate than the other. They just offer different strength.

The plus side for railway (as compared D exceptions): Easier comprehension of control flow and scope(exit) and scope(failure) are not needed anymore. Using something like this in @nogc functions seems easier than making exceptions work by preallocating them.

Haven't programmed anything of value in F# though.

On Monday, 12 January 2015 at 11:09:01 UTC, Walter Bright wrote:
> On 1/12/2015 3:02 AM, Tobias Pankrath wrote:
>> As far as I understand is, it requires each component to settle on the same
>> discriminated union that packs the error and result, which he calles Result but
>> is usually Choice in F#.
>>
>> Now in D we use the opDot to chain components, which works since we have UFCS.
>> In F# there a simply three different opDots: >>, >>= and >=> which take care of
>> the adaption.
>
> Or we could just use exceptions, which require none of that.

.. and have many other issues instead :)

Right now my experience from some quick experiments with Rust seems to indicate that it is a good sort inconvenience for medium-to-big applications as it forces you to explicitly consider all possible exceptional paths possible in application without and does not add any runtime overhead.

For smaller / less important programs verbosity does seem inconvenient in an unpleasant way indeed.

On 1/12/15, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> I've found another problem with Windows Moviemaker, it can read, but cannot
>
> write, movies larger than 4Gb. Looks like some sort of internal 32 bit overflow.

If you haven't read this I highly recommend it, just for the
entertainment value:
http://blog.seattlepi.com/microsoft/2008/06/24/full-text-an-epic-bill-gates-e-mail-rant/

On 1/12/2015 3:27 AM, Dicebot wrote:
> .. and have many other issues instead :)
>
> Right now my experience from some quick experiments with Rust seems to indicate
> that it is a good sort inconvenience for medium-to-big applications as it forces
> you to explicitly consider all possible exceptional paths possible in
> application without and does not add any runtime overhead.
>
> For smaller / less important programs verbosity does seem inconvenient in an
> unpleasant way indeed.

For me the primary advantage of EH is put the code to deal with the error in the place where it is most appropriate to deal with it. With error codes, you have to deal with propagating the errors everywhere. Error codes still require manual insertion of unwinding code, and that can get fairly ugly when dealing with transactions:

  http://dlang.org/exception-safe.html

Scope guard and RAII deal with most of the issues with having correct error recovery.

On Monday, 12 January 2015 at 11:41:06 UTC, Walter Bright wrote:
> For me the primary advantage of EH is put the code to deal with the error in the place where it is most appropriate to deal with it. With error codes, you have to deal with propagating

Does this mean that D will get fast EH?

On 1/12/2015 3:28 AM, Andrej Mitrovic via Digitalmars-d wrote:
> If you haven't read this I highly recommend it, just for the
> entertainment value:
> http://blog.seattlepi.com/microsoft/2008/06/24/full-text-an-epic-bill-gates-e-mail-rant/


Epic! But we all have such issues. And it ain't just software, either, every machine that has a user interface, like cars and airplanes and dishwashers, have these usability issues that are so obviously wrong yet nobody thought of them.

On Monday, 12 January 2015 at 11:43:26 UTC, Ola Fosheim Grøstad wrote:
> Does this mean that D will get fast EH?


It is fast already...

On Monday, 12 January 2015 at 11:09:01 UTC, Walter Bright wrote:
> On 1/12/2015 3:02 AM, Tobias Pankrath wrote:
>> As far as I understand is, it requires each component to settle on the same
>> discriminated union that packs the error and result, which he calles Result but
>> is usually Choice in F#.
>>
>> Now in D we use the opDot to chain components, which works since we have UFCS.
>> In F# there a simply three different opDots: >>, >>= and >=> which take care of
>> the adaption.
>
> Or we could just use exceptions, which require none of that.

Interesting little rant about exceptions (and more), from the author of a large and successful project in C++     http://250bpm.com/blog:4