On Friday, 29 May 2015 at 10:40:22 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
>> The trick is getting something (anything) to shift to D in the office,
>> giving other programmers some exposure, and give us a context to
>> experiment with D in application to our particular workload; that is,
>> realtime processing and rendering of geospatial data, an ideal
>> workload for D in my mind! http://udserver.euclideon.com/demo (demo is
>> NaCl + Emscripten, we'd love to have written it in D!)
>
> Are you working with Euclideon / Bruce Dell? Sounds fun!
>
> I am not using D for anything serious:
>
> 1. Partially because C++/clang is more mature and does a better job for real time audio. I am using my own libraries that provides the features D has, but C++ lacks.
>
> 2. Since not using C++ at all is not an option, I've had to spend more time than I've enjoyed figuring out how to do C++14 style meta programming, which is annoying and somewhat time consuming. D is better, in some areas, but lacking in others. So metaprograming is not a good enough reason to switch.

This is very interesting. It kinda defeats the "D is too complicated" argument I often hear.

> 3. D's memory model is up in the blue, C++ has locked down on one model, Rust on another. I am currently starting to think that Rust is a more likely option than D given the direction D might be taking towards reference counting etc. But I am not using Rust either… just watching how it develops.

And if D offered various models (cf. std.allocator), would you still prefer languages with just one model for the sake of simplicity and not having to worry about which model to choose?

On Friday, 29 May 2015 at 09:22:56 UTC, Martin Nowak wrote:
> On Thursday, 28 May 2015 at 20:22:44 UTC, rumbu wrote:
>> - lack of a decimal data type - you cannot perform monetary calculation using floating point.
>
> http://dlang.org/phobos/std_bigint.html?

No. There is no scale in BigInt. 1 / 2 will result in 0 not in 0.5. If BigInt in D was inspired from java BigInt, the direct equivalent should be java BigDecimal, but this does not exist in phobos. Even if I keep a scale myself, there are missing features like rounding. Anyway, I implemented my own decimal type : https://github.com/rumbu13/sharp/blob/master/src/system/package.d#L2512, but I would prefer that D will provide such types built in the language, at least this was the intention many years ago: http://dlang.org/d-floating-point.html

>
>> - lack of a chinese or japanese calendar in the std.datetime module;
>> - missing of overflow checks for integral data types;
>
> http://dlang.org/phobos/core_checkedint.html

Division overflow is not implemented (int.min / -1) and using a linear syntax instead of a simple expression is not the best way to convince people to switch sides.

On 2015-05-28 22:22, rumbu wrote:

> - lack of a chinese or japanese calendar in the std.datetime module;

What about Tango [1]?

[1] http://dsource.org/projects/tango/docs/current/tango.time.chrono.Japanese.html

-- 
/Jacob Carlborg

On Friday, 29 May 2015 at 12:23:14 UTC, rumbu wrote:
> On Friday, 29 May 2015 at 09:22:56 UTC, Martin Nowak wrote:
>> On Thursday, 28 May 2015 at 20:22:44 UTC, rumbu wrote:
>>> - lack of a decimal data type - you cannot perform monetary calculation using floating point.
>>
>> http://dlang.org/phobos/std_bigint.html?
>
> No. There is no scale in BigInt. 1 / 2 will result in 0 not in 0.5. If BigInt in D was inspired from java BigInt, the direct equivalent should be java BigDecimal, but this does not exist in phobos. Even if I keep a scale myself, there are missing features like rounding. Anyway, I implemented my own decimal type : https://github.com/rumbu13/sharp/blob/master/src/system/package.d#L2512,

Fair play to you! We should bundle these efforts. What about a page where we collect all this stuff like "I miss this feature in D, and here's my own library for it." We all have stuff like this in the attic somewhere.

> but I would prefer that D will provide such types built in the language, at least this was the intention many years ago: http://dlang.org/d-floating-point.html
>
>>
>>> - lack of a chinese or japanese calendar in the std.datetime module;
>>> - missing of overflow checks for integral data types;
>>
>> http://dlang.org/phobos/core_checkedint.html
>
> Division overflow is not implemented (int.min / -1) and using a linear syntax instead of a simple expression is not the best way to convince people to switch sides.

On Friday, 29 May 2015 at 12:52:12 UTC, Jacob Carlborg wrote:
> On 2015-05-28 22:22, rumbu wrote:
>
>> - lack of a chinese or japanese calendar in the std.datetime module;
>
> What about Tango [1]?
>
> [1] http://dsource.org/projects/tango/docs/current/tango.time.chrono.Japanese.html

The Japanese Calendar is Gregorian, so there are no major differences. On the contrary the Chinese one is very different with floating month sizes. If someone is wondering why a calendar is needed in a payroll calculation, it's used to determine the number of working days in a month :)

Tahngo was nice but not supported anymore, I expect these features in phobos.

On Friday, 29 May 2015 at 11:29:13 UTC, Chris wrote:
> This is very interesting. It kinda defeats the "D is too complicated" argument I often hear.

I don't know what is typical, but I am dealing with Python, Javascript, Dart, C++ and Objective-C for commercial use, and plan on adding Swift. C++14 is by far the most taxing, due to not enough rigour in the language design (complications with no benefits!). Dart you can master in a week, and is more productive than C++. So I have a lower threshold for adding a "Dart-like" language with an IDE than a "C++-like" language for commercial use. My threshold for adding Swift is very low due to the perceived simplicity and decent tooling.

>> 3. D's memory model is up in the blue, C++ has locked down on one model, Rust on another. I am currently starting to think that Rust is a more likely option than D given the direction D might be taking towards reference counting etc. But I am not using Rust either… just watching how it develops.
>
> And if D offered various models (cf. std.allocator), would you still prefer languages with just one model for the sake of simplicity and not having to worry about which model to choose?

I would prefer one clean heap-model that the compiler can optimize easily + compiler backed stack allocation, and that most third party libraries are written for. Almost all my performance oriented allocations are on the stack or are preallocated in big blocks, so I'd put more emphasis on things like VLA (which is available as a C++ extension in clang/gcc).

There is no way a generic solution can beat a tailored solution when it comes to abstract datatypes and memory management, so having lots of options in a standard library sounds useful.

But interoperability matters more. Like, I am likely to use Swift for ios/osx GUI, but need a companion language for the core application engine. C++ is most likely today. If Rust or D makes integration with Swift easy then I would consider a switch. The bottom line is overall productivity, long term maintenance and risk for hitting an issue that requires "ugly unsupported hacks".

It is much more difficult to find a place for a "middle ground" solution than a very focused heavy duty solution or a very light solution that is easy to get on with. I don't think people look for "middle ground" solutions when the try to solve a problem.

On Friday, 29 May 2015 at 14:03:19 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 29 May 2015 at 11:29:13 UTC, Chris wrote:
>> This is very interesting. It kinda defeats the "D is too complicated" argument I often hear.
>
> I don't know what is typical, but I am dealing with Python, Javascript, Dart, C++ and Objective-C for commercial use, and plan on adding Swift. C++14 is by far the most taxing, due to not enough rigour in the language design (complications with no benefits!). Dart you can master in a week, and is more productive than C++. So I have a lower threshold for adding a "Dart-like" language with an IDE than a "C++-like" language for commercial use. My threshold for adding Swift is very low due to the perceived simplicity and decent tooling.

D is not perceived as a simple language, although it can be trivial to use sometimes. To simply get things done the languages mentioned above are certainly a good choice and if you develop for mobile phones, D is certainly not a good choice _at the moment_.

However, for a constantly growing long-term code base, D is my language of choice. It's clean (i.e. maintainable), flexible (many ways to tackle new problems), easily unit-testable and, of course, compiles to native machine code. It also interfaces to C(++) which is very important.

>>> 3. D's memory model is up in the blue, C++ has locked down on one model, Rust on another. I am currently starting to think that Rust is a more likely option than D given the direction D might be taking towards reference counting etc. But I am not using Rust either… just watching how it develops.
>>
>> And if D offered various models (cf. std.allocator), would you still prefer languages with just one model for the sake of simplicity and not having to worry about which model to choose?
>
> I would prefer one clean heap-model that the compiler can optimize easily + compiler backed stack allocation, and that most third party libraries are written for. Almost all my performance oriented allocations are on the stack or are preallocated in big blocks, so I'd put more emphasis on things like VLA (which is available as a C++ extension in clang/gcc).
>
> There is no way a generic solution can beat a tailored solution when it comes to abstract datatypes and memory management, so having lots of options in a standard library sounds useful.
>
> But interoperability matters more. Like, I am likely to use Swift for ios/osx GUI, but need a companion language for the core application engine. C++ is most likely today. If Rust or D makes integration with Swift easy then I would consider a switch. The bottom line is overall productivity, long term maintenance and risk for hitting an issue that requires "ugly unsupported hacks".
>
> It is much more difficult to find a place for a "middle ground" solution than a very focused heavy duty solution or a very light solution that is easy to get on with. I don't think people look for "middle ground" solutions when the try to solve a problem.

My approach has been similar. The GUI could be anything, the core is D. I don't want to rewrite core functionality in various languages, and with other languages I always hit a wall that says "Thus far shalt thou go and no further!"

On Friday, 29 May 2015 at 14:22:58 UTC, Chris wrote:
> However, for a constantly growing long-term code base, D is my language of choice. It's clean (i.e. maintainable), flexible (many ways to tackle new problems), easily unit-testable and, of course, compiles to native machine code. It also interfaces to C(++) which is very important.

Yes, C++ interfacing could prove important, if it can cover >95% of C++ library interfaces.

Are you using D for a constantly growing long-term code base, or planning to?

>> There is no way a generic solution can beat a tailored solution when it comes to abstract datatypes and memory management, so having lots of options in a standard library sounds useful.

Ugh, I said the opposite of what I meant. I don't think having lots of allocation options in a standard library sounds all that useful, since I will most likely roll my own when hitting a serious performance problem. Rolling your own is often the same amount of work as "searching for  a narrow solution" unless you are doing something really complicated.

I think many standard libraries could be cut down to the most generally useful functionality. In C++ I use std::array or my own data structures, I only occasionally use std::vector… In Python I use no more than 5% of the standard library. Generally useful solutions (like comprehensions) beats narrow solutions 99% of the time, because when you need something narrow then the pre-canned narrow solutions often require hacks to serve the purpose (the wrong kind of narrowness or "fits perfectly except it doesn't work when…X…").

On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
> I expect I'm not alone. Please share the absolute blockers
> preventing you from adopting D in your offices.

If awareness of its existence weren't a problem, it wouldn't be a long list.  Mostly SPARC/Solaris and Politics (including inertia of the current approach).

-Wyatt

On Friday, 29 May 2015 at 13:45:56 UTC, rumbu wrote:
> Tahngo was nice but not supported anymore

Two months ago it had an update that bumped tested version to 2.067.