On Wednesday, 30 September 2015 at 17:12:37 UTC, Mengu wrote:
> what is libucrtd.lib

http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

"The Universal CRT is a Windows operating system component. It is a part of Windows 10. For Windows versions prior to Windows 10, the Universal CRT is distributed via Windows Update."

On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:
> My experiences with D recently have not been fun.
>
> The language itself has a top notch feature rich set. The implementation, excluding bugs, feels a bit boxy and old school. .NET has a unified approach and everything seems to fit together nicely and feels consistent. The abomination of dmd, though, is it's error messages. Most of them are meaningless and you have to dive down 2 or 3 levels of assumptions to figure out what they mean. It's not too bad but because of the poor tool set it makes it difficult to debug apps.
>
> [...]

I got many *many* years experience of .NET, and I find C# as a quite nice language. I like the Interface construct (and many more things). I tried mono, and find it a very interesting project, but it also has lots of stuff unimplemented and some of the stuff can't be done (Windows specific), since Xamarian targets multiple platforms with their .NET version.

But go ahead! :-)

On Wednesday, 30 September 2015 at 16:52:21 UTC, Adam D. Ruppe wrote:
> On Wednesday, 30 September 2015 at 09:49:34 UTC, rumbu wrote:
>> I would believe that when core.sys.windows will have the same amount of code like core.sys.posix after the default installation.
>
> I'm unbelievably close to that now, I just have a million other things to do (...including adding Linux headers that are missing from druntime too. it is less Linux- or Windows- centric and more "the smallest amount of work the core devs can possibly do that is useful"- centric)
>
>> Or when mscoff32 libs will be included in setup.
>
> dmd -m32mscoff generates those files and links with the Microsoft linker. It just works when I try it on my computer (which already has VS installed btw).
>
>> Or when the libs from windows\lib will not have a content from 15 years ago.
>
> I might change that too though I'm not in as much of a rush since the 32mscoff and 64 don't use them anyway; they use the up-to-date MS sdks.

I want to personally thank you Adam for your efforts. My complaint was not about availability (updated WinAPI headers are around since D1 era), but about the fact that these headers were never a "first class" citizen of the dmd setup like the posix ones. Another problem was that even the headers were available, the corresponding libs were not updated, and each time I must run coffimplib to update them.

Like you said, using mscoff32 format will make them useless anyway.

Again, thank you for keeping them up to date and including them in the default setup, if possible.

When I say mscoff32 libs, I'm especially thinking about phobos, but this seems solved partially (curl32mscoff.lib is missing) in the last version.

On Wednesday, 30 September 2015 at 17:32:27 UTC, Adam D. Ruppe wrote:
> On Wednesday, 30 September 2015 at 17:12:37 UTC, Mengu wrote:
>> what is libucrtd.lib
>
> http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx
>
> "The Universal CRT is a Windows operating system component. It is a part of Windows 10. For Windows versions prior to Windows 10, the Universal CRT is distributed via Windows Update."

That doesn't apply to link stage. And libucrtd.lib is a (not recommended) static universal crt.

On Wednesday, 30 September 2015 at 12:21:10 UTC, Ola Fosheim Grøstad wrote:
>
> The reason is much more likely that the expectations are set at a level where D does not deliver. If you want a production environment to be judged favourably it is a good idea to set the expectations one notch below what you deliver. There is a bit too much hubris in how D is portrayed and therefore you get a backlash, from actual D users.

I agree that the D community raises the bar quite high for itself and other people might get the impression that everything is perfect, while it isn't. However, a lot of complaints are about IDEs, one click installers (i.e. the tools) and not about how D handles floating point numbers.

Could you line out how you would like a language to be so it doesn't bore you stiff?

On Thursday, 1 October 2015 at 16:00:29 UTC, Chris wrote:
> I agree that the D community raises the bar quite high for itself and other people might get the impression that everything is perfect, while it isn't. However, a lot of complaints are about IDEs, one click installers (i.e. the tools) and not about how D handles floating point numbers.

Well, I am less concerned about those that stumble on the doorstep. If that is enough to not carry on then they are most likely not motivated and can probably get their needs covered elsewhere. I am more concerned about those that use D for what it is particularly well suited for (systems and OS-level programming) and give up after writing some tools with it.

> Could you line out how you would like a language to be so it doesn't bore you stiff?

Consistency in philosophy is important. If D is a compile time oriented library authors language (and I think it is) then that needs to come to the forefront so that library authors easily can write beautiful code and easily integrate D code with other environments. The runtime dependencies must be kept low and the focus on powerful and easy to use compile time resolution and static analysis has to be strengthened.

There is a lot of competition in this domain right now with C++17, Rust and some 3rd party things going on in the Go sphere on one side and Pony, Nim, Loci, Crystal and quite a few others upcoming projects. In addition a plethora of scientific languages and toolkits are appearing on the horizon thanks to commoditised JIT/backends. Even Haskell seems to be gaining a little bit of ground, doesn't Facebook use Haskell for spam detection or something?

With so many emerging languages it is important to stay true to ones strengths and not overfocus on application domains that most likely will be taken over by domain oriented high level programming languages in a ten year time frame.

On Monday, 5 October 2015 at 15:01:14 UTC, Ola Fosheim Grøstad wrote:
> Well, I am less concerned about those that stumble on the doorstep.


> If that is enough to not carry on then they are most likely not motivated and can probably get their needs covered elsewhere.

Respectfully, I think helping new users get a jump start on their application produces an initial jolt of productivity which in turn helps keep someone motivated.

> I am more concerned about those that use D for what it is particularly well suited for (systems and OS-level programming) and give up after writing some tools with it.
>

I prefer Andrei's mantra of "...being good at everything C and C++ are good at, and also by being good at many tasks that C and C++ are not good at..."

https://yow.eventer.com/yow-2014-1222/cool-things-about-d-why-and-how-we-use-it-at-facebook-by-andrei-alexandrescu-1741

On Monday, 5 October 2015 at 15:46:35 UTC, Jeremy wrote:
> Respectfully, I think helping new users get a jump start on their application produces an initial jolt of productivity which in turn helps keep someone motivated.

Jump-starting does not keep them motivated. It makes them invest initially, but at this point retention of a specific type of developers (compiler/runtime capable developers) is more important than recruitment of all kinds of developers.

Rust is taking a lot of that market. Understanding why and doing something about it, is important.

> I prefer Andrei's mantra of "...being good at everything C and C++ are good at, and also by being good at many tasks that C and C++ are not good at..."

That's just a mantra, C++ and D are pretty close as far as library authoring goes, but currently D represents lock-in compared to C/C++, provides much fewer options than C++14 compilers/extensions/tooling, also semantically. That is unlikely to change without a focused direction that also takes C++17/20 and Rust into account.

D isn't competing with C++14 / Rust 1.0, it is competing with C++17/20 and Rust 1.X, due to the time it takes to polish. But it is impossible to do anything focused without defining what the target is. And that lack of a focused strategy that is currently a main issue with D's future, because the rest of the programming world _is_ moving.

Here's an entertaining video about the actor model, that represent one established programming model that C++ is not so good at currently (but may become better at):

https://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask

On Monday, 5 October 2015 at 15:01:14 UTC, Ola Fosheim Grøstad wrote:

>> Could you line out how you would like a language to be so it doesn't bore you stiff?
>
> Consistency in philosophy is important. If D is a compile time oriented library authors language (and I think it is) then that needs to come to the forefront so that library authors easily can write beautiful code and easily integrate D code with other environments. The runtime dependencies must be kept low and the focus on powerful and easy to use compile time resolution and static analysis has to be strengthened.

Ok, and do you have a plan or a concrete wish list that you could hand over to the core developers? What features would be indispensable or are of utmost importance, in your opinion? Do you have prototypes or made pull requests?

On Tuesday, 6 October 2015 at 17:07:27 UTC, Chris wrote:
> Ok, and do you have a plan or a concrete wish list that you could hand over to the core developers? What features would be indispensable or are of utmost importance, in your opinion?

1. Define the target, then you can figure out the features.
2. Solid non-gc memory management and ownership.
3. Clean up the type system.
4. Complete the language spec.
5. Clean up the syntax.
6. Extend support to critical platforms like WebAssembly/asm.js

> Do you have prototypes or made pull requests?

I have some prototypes for my own use, but not sure what relevance that has? Pull requests would require decision making and policy changes, and be utterly pointless without it. Design/policy changes will have to start with the project leaders, that's the only way. End-users do not directly affect language features.