On Friday, 29 May 2015 at 14:46:06 UTC, Ola Fosheim Grøstad wrote:
> 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?

I've been using D for a long-term project for quite a while now.

>>> 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. I wonder if there will be common
> themes emerge?

I do use it at work, but I also don't really have a collaborative codebase. These are usually assistant programs/scripts, our primary product is web-based and runs on IIS. I do QA work so not involved in the Android/iOS work. I've had complaints that I was using D and others wouldn't want to learn it to help contribute, switching to our company language (C#) didn't help in getting on-board to contribute to my projects. I'm back to writing whatever I can in D.

On Friday, 29 May 2015 at 10:32:50 UTC, Martin Nowak wrote:
> On Friday, 29 May 2015 at 09:50:29 UTC, weaselcat wrote:
>> Walter said likely/unlikely won't be implemented as the compiler already assumes the first condition is the more likely one the last time this was brought up.
>
> That is not what he said http://forum.dlang.org/post/m8739b$an$1@digitalmars.com.

Wow, I shouldn't post before going to bed.
My apologies, remembered it way differently. Sorry for the noise.

On Friday, 29 May 2015 at 12:55:13 UTC, Chris wrote:
> 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.

http://code.dlang.org/

On 29 May 2015 at 02:40, Meta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> Wait, you work for Euclideon?

Yeah. And I'd say our work is a killer use-case for D!

On 2015-05-29 15:45, rumbu wrote:

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

It's supported in the sense that someone always makes sure it works with latest DMD.

-- 
/Jacob Carlborg

On 2015-05-29 16:03, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:

> 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.

For Swift interfacing with C++ you would need a C or Objective-C layer. With the Objective-C support in D (if it will ever be merged) you could have a more direct interface, but it would be limited to the Objective-C subset.

-- 
/Jacob Carlborg

On 2015-05-28 16:38, Manu via Digitalmars-d wrote:
> I've been using D in all my personal projects for years now, but I
> lament coding C at work every day, and I pine for salvation.
> I seem to have reasonable influence in my workplaces, and I suspect I
> could have my workplace adopt D, but when considering the notion with
> other staff, we always seem to encounter hard blockers to migration
> that stop us in our tracks.
>
> I expect I'm not alone. Please share the absolute blockers preventing
> you from adopting D in your offices. I wonder if there will be common
> themes emerge?

I have never (seriously) suggested to use D at my work and rarely even think about it because I feel it's hard to justify.

We're mostly developing the backend part of a web based system, with a lot of services. Currently we're using Ruby for basically all code. There's a couple services written in Go (for performance reason) and one or two legacy systems in Java.

We don't have a lot of the issues others have posted here. We don't need to run on Andriod/iOS, we don't need a GUI and our code is not as performance sensitive that we need to use @forceinline or SIMD.

The biggest issue I see is the lack of libraries. I have not investigated exactly what we would need but what I do know we need is:

* Web framework (vibe.d could be used)
* ORM
* Connection to Postgres
* A good testing framework (i.e. something like RSpec)

That's the bare minimum I can think of for now. I know there exist Dub packages for some of these but with Ruby it feels much more "safe" to use. The Ruby community is so much bigger, so many more developers are using the same libraries we're using compared to how it would be in D. It's not like Rails or RSpec are suddenly going to disappear.

The GC might be another issue, at least if you look at how many objects are created in Ruby. But in D it would be easier to avoid heap allocations.

-- 
/Jacob Carlborg

I have been doing my first serious attempt at D after convincing other
people that it was the way to go quite a few years ago. (My copy of
"The D Programming Language" doesn't have Andrei's name on it so it
would have been around that time)
and these are the things which are fresh for me.

I had no idea that it was so easy to call C code from my D code, and
how little effort I had to go to disguise the fact that it was C code
thanks mostly to UFCS and @property.
This makes it feasible to write bindings on the fly and makes me a lot
less hesitant to try using it for any job I could use C or C++.

So far so good.

Now lets get to the friction points.

Tooling - it's still a step down from what I am used to with C/C++ on linux. This is now for me at the point where it is acceptable but not great.

Documentation - What is there is generally quite good, also quite terse. I am not seeing a huge number D specific results whenever I search on any issues I am having with my code.

The Standard Library. I want to use D so I can do more with less hours writing code and less hours debugging code. Having a high quality standard library really helps this - unfortunately for me the first thing I needed from the standard library was xml parsing, which the documentation tells me is sub par and will be replaced in the near future, There is no indication of what I might like to use instead. Do I now use one of the other xml libraries floating around, bind a C based one or roll my own. All this eats into the efficiency that I am gaining by virtue of D being a really nice language.

On 31/05/2015 11:37 a.m., Danni Coy via Digitalmars-d wrote:
> I have been doing my first serious attempt at D after convincing other
> people that it was the way to go quite a few years ago. (My copy of
> "The D Programming Language" doesn't have Andrei's name on it so it
> would have been around that time)
> and these are the things which are fresh for me.
>
> I had no idea that it was so easy to call C code from my D code, and
> how little effort I had to go to disguise the fact that it was C code
> thanks mostly to UFCS and @property.
> This makes it feasible to write bindings on the fly and makes me a lot
> less hesitant to try using it for any job I could use C or C++.
>
> So far so good.
>
> Now lets get to the friction points.
>
> Tooling - it's still a step down from what I am used to with C/C++ on
> linux. This is now for me at the point where it is acceptable but not
> great.
>
> Documentation - What is there is generally quite good, also quite
> terse. I am not seeing a huge number D specific results whenever I
> search on any issues I am having with my code.
>
> The Standard Library. I want to use D so I can do more with less hours
> writing code and less hours debugging code. Having a high quality
> standard library really helps this - unfortunately for me the first
> thing I needed from the standard library was xml parsing, which the
> documentation tells me is sub par and will be replaced in the near
> future, There is no indication of what I might like to use instead. Do
> I now use one of the other xml libraries floating around, bind a C
> based one or roll my own. All this eats into the efficiency that I am
> gaining by virtue of D being a really nice language.
>


Ahh std.xml, it's been that way for years.
We NEED to get that replaced. Although don't hold your breath :/