>> On 10/6/2017 10:19 PM, Adam Wilson via Digitalmars-d wrote:
>> > What if we stop focusing on the C/C++ people so much? The like their tools and have no perceivable interest in moving away from them (Stockholm Syndrome much?). The arguments the use are primarily meant as defensive ploys, because they compare everything to C/C++ and when it doesn't match in some way or another the other language must be deficient. They've already decided that C/C++ is the meter stick against which all other languages are to be judged. Unsurprisingly, nothing that is NOT C/C++ meets their exacting demands.

Yes - as Andrei said in a talk, people are looking for an excuse not to have to take the time to learn something new.  There's an inordinate strength of feeling in discussions in relation to D.  If it's not your cup of tea, why do you care so much?  The raising of spurious objections is much better than indifference at this point, and you can see this year that there has been a shift.  People got downvoted for repeating the same old talking points that are now demonstrably not correct, whereas before it was a matter of judgement and people could reasonably differ.


> On Friday, October 06, 2017 23:19:01 Brad Roberts via
>> Or recognize that painting huge diverse groups as if there's a single brush with which to do so is a huge fallacy.  Consider that the two leaders, as well as a large number of the contributing developers, come from the c++ community and that's not a bad thing, but rather a big part of _why_ they came to D.
>>
>> As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers.  Luckily, that's how things tend to proceed here, so yay for that.

Long tail.  We really couldn't care less about what most people think.  In fact it's good that most people won't try D because what they will be expecting isn't yet what we offer (glossiness and hand-holding).

At any one time there is a proportion of people who are unhappy with their existing choices and looking for something better.  It's easy to grow in the early days - you don't need to appeal to most programmers.  You just need to have a slightly stronger appeal to those who are already predisposed to like you (and to those who are already using your language and would like to use it for more things).

And people conceive of the market in too small a way.  People talk as if languages are in a battle to the death with each other - D can't succeed because it's too late, or because Rust has momentum.  But the world is a very big place, and the set of people who talk much to a broad audience about what they are doing is a small one and thinking it reflects reality leads to distorted perceptions.

Who would have thought that probably one of the larger code bases (500k SLOC) to be rewritten/converted in D might come from Pascal, with D competing with ADA?  I don't know what has been decided there, but whatever the outcome, that's highly interesting, because it's probably true of others.

Similarly Weka came from nowhere.  A random tweet by Fowler led to them building their entire company on a language the founders hadn't used before.

Because D is a highly ambitious language that isn't confined to a single domain, and that's a potential replacement in some domains for many other languages, most people won't know anyone who uses D because use is much more spread out.  Enterprise users outside of web + big tech/startups don't talk about their choices that much.  Microsoft didn't send out a press release when they used D in their COM team, for example - someone there just figured it was a good tool for the job and got on with it.  Similarly the company that Andy Smith worked for (a money management company) didn't say anything, and it only happened that he talked about it because I suggested it and he happened to have time.

Inordinately at this point in its development D is going to appeal to principals over agents, to people who have at least local authority to make decisions and don't have to persuade others, because the dynamics of how you persuade a committee are based on quite different things than making a decision and living or dying by how it turns out.

That's okay.  If people don't feel they can use D at work, they shouldn't.  Some people will be able to, and as they have some success with it, others will start to imitate them.  And in the meantime maybe it will be an advantage of sorts for the earlier adopters.

It matters who your customers are, because that shapes what you become.  And it's better early on to have people who make decisions on technical merits and who have the authority to do so, then to have a representative enterprise buyer!


On Saturday, 7 October 2017 at 08:36:01 UTC, Jonathan M Davis wrote:
> Honestly, I've gotten to the point that I don't care much about trying to appeal to folks who complain about D. If we just make the language the best that we can, that will attract folks - that's largely what's attracted them in the past. Sure, we could and probably should do better with marketing D, and some of the complaints that get leveled at the language are valid and should be addressed, but trying to convince folks who are already convinced that they don't like D just doesn't seem like a good way to spend our time and energy.

I agree with both parts.  It doesn't do any harm to continue to work on getting the language's merits across.  There's no point entirely hiding our light under a bushel.  But doing good work and making the language and ecosystem better is by far more important because that's what matters and we're in a time when people will eventually get it even if they don't all currently.

> Complaints from folks not using D _can_ help shows us areas in which we're deficient, but they're not necessarily right, and they're not our actual user base.
Yes.  (I'd put the emphasis on _help_)


> And really, what we need is a good language with good tools that supports a vibrant community of those who want to use it. We want that community to grow, because it will help the language and make it easier to get jobs using it, but it's not like we need to convince the whole world to use D - not to mention that there are classes of folks that we don't want; their views and goals just differ too much from ours

People seem to think language decisions are only about technical questions.  But they're as much about values, and you're never going to get people to agree about values because people are facing different problems and are themselves different kinds of people.

https://vimeo.com/230142234  Bryan Cantrill of Joyent nails it


>  which is part of why having a diverse set of languages out there can actually be valuable. Different folks prefer different languages, and trying to get everyone to agree is never going to work. As long as D is sucessful enough that those of us who want to use it can use it and do what we need to get done, then that should be plenty. If more folks decide that they like what D's offering, then great. If they prefer C++ or C# or Rust or whatever, then they can have fun doing whatever they need to do with those languages, and we won't have to make changes to D just to make them happy.
>
> - Jonathan M Davis


In a polyglot environment, D's code generation and introspection abilities might be quite valuable if it allows you to write core building blocks once and call them from other languages without too much boilerplate and bloat.  One could use SWIG, but...

On Saturday, 7 October 2017 at 20:44:44 UTC, Adam D. Ruppe wrote:
> On Saturday, 7 October 2017 at 20:36:24 UTC, Laeeth Isharc wrote:
>> Would it make sense to have a BetterC version define for Phobos?
>
> Quite a lot of Phobos already works that way.

blog post to enlighten the masses?

On Saturday, 7 October 2017 at 21:08:42 UTC, Laeeth Isharc wrote:
> Who would have thought that probably one of the larger code bases (500k SLOC) to be rewritten/converted in D might come from Pascal, with D competing with ADA?  I don't know what has been decided there, but whatever the outcome, that's highly interesting, because it's probably true of others.

Nothing has been decided yet. More work needs to be done in determining where we can push the compatibility boundary. I was looking for ways to maintain binary compatibility with our existing datastructures and file formats, when my attention was needed for another big assignment. Our research into languages has been on hold since then. I hope to make some progress this winter. It is going to take time though, this is a task full of interesting challenges. But I am convinced that if we can find a way to translate to D, it will be an important move for the future of our company.

Bastiaan.

On 10/7/2017 1:36 PM, Laeeth Isharc wrote:
> Would it make sense to have a BetterC version define for Phobos? Or is this a terrible idea?  So you could still use some subset of Phobos from BetterC mode, and maybe this subset could be expanded over time?  And maybe people would write a complimentary set of functions to cover the missing most useful things in a way that doesn't depend on the runtime?

It does make sense in general for library functions to be less dependent on linking to the rest of the library. For example, I discovered recently that core.stdc.stdio and core.stdc.errno relied on linking in druntime, making them unusable for BetterC.

Fortunately, I found a way to remove those dependencies without any compromises. Of course, this won't always be possible, but it is worth thinking about when designing Phobos code.

(One way to do this is to use more templates, as the templates will get instantiated into the user program rather than needing to be linked in from Phobos.)

On Saturday, 7 October 2017 at 06:19:01 UTC, Brad Roberts wrote:
>
> As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers.  Luckily, that's how things tend to proceed here, so yay for that.

Doesn't feel like that when the views of the people in charge don't align with what people are saying. I can understand people's dissatisfaction with Windows, but some people take it too far. The compiler for Windows is built using 32-bit, not only is the 64-bit version not built it's not even supported or tested. I think someone made a post a little while ago about LDC that 95% or more of downloads for their compiler were for the 64-bit version. If only one version is to be supported then it should be the 64-bit version. I can't even imagine the outrage there would be if 64-bit wasn't supported on Linux. Hell, they haven't even bothered setting up AppVeyor for dmd, free testing on Windows. Niche within a niche, can't expect much I guess.

On Saturday, 7 October 2017 at 20:36:24 UTC, Laeeth Isharc wrote:
> On Saturday, 7 October 2017 at 09:37:12 UTC, Radu wrote:
>> I think there is some merit criticizing D's GC.
>>
>> The major problem with it ATM is that there is no convenient way to use all (most) of D's std lib without it.
>>
>> This also extends to third party libs - most of them are coded with the GC in mind because of the above point.
>
> I guess a non-GC solution for throw new Exception will help with quite a lot.  What to do about the rest (at least for Phobos)?
>

Yes, exceptions are one, but there are strings (arrays in general) for which ref counted needs to work, and it should work in @safe mode, so you need scope working to get it...

>> - Allocators - right now they are in Phobos... This is not great, they should be split in 2 parts: core an druntime. One should be able to use a minimal set in betterC mode, and the full version with druntime (all GC related parts).
>
> Would it make sense to have a BetterC version define for Phobos?  Or is this a terrible idea?  So you could still use some subset of Phobos from BetterC mode, and maybe this subset could be expanded over time?  And maybe people would write a complimentary set of functions to cover the missing most useful things in a way that doesn't depend on the runtime?
>

It would make sense to have a documentation marker that allows one to quickly see that a module/function is usable in betterC mode. Algorithms and the like are first in line but it should be gradually extended to all parts of phobos... Right now this is a guess work.

> It makes sense what you say about allocators - it would be nice to be able to write BetterC code using those.  I used dscanner quickly to see what the imports are, and I wonder how much work it would be to do what you propose.
>

Yeah - they are entangled with a lot of parts from druntime and phobos, that's why I think they need a redesign that can deliver a core part that works with the C runtime (betterC), then extend on that to have the druntime one.

> core.atomic
> core.bitop
> core.exception
> core.internal.spinlock
> core.memory
> core.stdc.errno
> core.stdc.stdlib
> core.stdc.string
> core.sys.posix.pthread
> core.sys.posix.sys.mman
> core.sys.windows.unknwn
> core.sys.windows.windows
> core.thread
> std.algorithm.comparison
> std.algorithm.iteration
> std.algorithm.mutation
> std.algorithm.searching
> std.algorithm.sorting
> std.array
> std.c.stdlib
> std.c.string
> std.concurrency
> std.conv
> std.exceptionstd.file
> std.format
> std.internal.test.dummyrange
> std.math
> std.meta
> std.random
> std.range
> std.range.primitives
> std.stdio
> std.traits
> std.typecons

On Sunday, 8 October 2017 at 04:23:50 UTC, Jerry wrote:
> On Saturday, 7 October 2017 at 06:19:01 UTC, Brad Roberts wrote:
>>
>> As always, focusing on the users of the language tends to pay a lot more dividends than focusing on nay sayers.  Luckily, that's how things tend to proceed here, so yay for that.
>
> Doesn't feel like that when the views of the people in charge don't align with what people are saying. I can understand people's dissatisfaction with Windows, but some people take it too far. The compiler for Windows is built using 32-bit, not only is the 64-bit version not built it's not even supported or tested. I think someone made a post a little while ago about LDC that 95% or more of downloads for their compiler were for the 64-bit version. If only one version is to be supported then it should be the 64-bit version. I can't even imagine the outrage there would be if 64-bit wasn't supported on Linux. Hell, they haven't even bothered setting up AppVeyor for dmd, free testing on Windows. Niche within a niche, can't expect much I guess.

You know it's not that hard to be the change you wish to see in the world.  That's really the whole point of open source, or at least of at least reasonably or more free software - you're not at the mercy of a paid vendor to whom you pay a fortune for the favour of them closing or otherwise creatively ignoring your tickets.  You can pretty easily fix many problems and irritations yourself, and if you're too busy then one can pay someone to do it, and if one is busy and has no money to spend right now one can try to persuade someone to work on it. But if one just grumbles, probably the result will be just what anyone would expect.

64 bit command line build didn't seem to work for a while.  That's been fixed recently, as I recall.  One can't really compare Linux and Windows 32 and 64 bit.  Those worlds work very differently.  Windows is as it is because they are fanatical about maintaining backwards compatibility.  So unless you run out of memory then 32 bit compiler isn't much of a restriction.  And if you are doing so much ctfe that you run out of memory, chances are you can figure out how to build the 64 bit compiler on Windows!

Try using digger - might work now that the 64 bit command line build works again.  And failing that maybe file a request on bugzilla.  And I don't know but I guess if you contribute something to the D Foundation, probably - because it's still quite new - it will be easier to get people to listen to a gentle request to have a downloadable 64 bit compiler.  These things do cost money, and right now I think somebody is paying for that out of the goodness of their heart...

On Saturday, 7 October 2017 at 15:12:08 UTC, Random D user wrote:
> Actually, Manual Memory Management is slow and D's GC is slower.

Well, no, deterministic memory management isn't slow. One specific implementation with a high level of naiveté might be slow.

C is not a very clever language, it was designed to be minimal and with minimal compiler requirements and with most features pushed onto libraries, including memory management. C++ is just meta-level dressing over C…

> Because, if malloc/free is slow (free is often slower), you want to avoid them as much as possible.

A naive generic library implementation that is used randomly will not be fast, but a more dedicated implementation for the program at hand could be very performant.

> You do this by reusing your memory/buffers.

Yes, in C/C++ you either have to resort to creating your own allocator in your program or you could used dedicated allocators. Or you just make them static global.

Anyway, D doesn't improve on C/C++ when it comes to allocators. And it's garbage collector is pretty much stuck in the standard GC implementation from 1960s/1970s in terms of performance and features.

Just because C/C++ is primitive doesn't mean that D is doing well, but at this point there is not much hope of D becoming a significant improvement on C++… So maybe it is better for D to stay where it is as there is basically very little support among the designers from improving the language semantics. In the C++ environment there is at least some movement, so maybe it will become a decent language in 2050, although they are stuck with the primitive C-foundation…

On Wednesday, 11 October 2017 at 07:33:26 UTC, Laeeth Isharc wrote:
> You know it's not that hard to be the change you wish to see in the world.  That's really the whole point of open source, or at least of at least reasonably or more free software - you're not at the mercy of a paid vendor to whom you pay a fortune for the favour of them closing or otherwise creatively ignoring your tickets.  You can pretty easily fix many problems and irritations yourself, and if you're too busy then one can pay someone to do it, and if one is busy and has no money to spend right now one can try to persuade someone to work on it. But if one just grumbles, probably the result will be just what anyone would expect.

You still are at the mercy of the people maintaining the project. Which is kind of no different than being at the mercy of a big company from my experience. Some people listen, but a lot of the time they don't if something contradicts their views (having to do anything regarding Windows in this case). I could fork it and then maintain things myself, but that means fixing any pull requests or changes in the future yourself. Which now becomes a full time job, where as using the project to begin with was the point of reducing the workload, not increasing it.


> 64 bit command line build didn't seem to work for a while.  That's been fixed recently, as I recall.  One can't really compare Linux and Windows 32 and 64 bit.  Those worlds work very differently.  Windows is as it is because they are fanatical about maintaining backwards compatibility.  So unless you run out of memory then 32 bit compiler isn't much of a restriction.  And if you are doing so much ctfe that you run out of memory, chances are you can figure out how to build the 64 bit compiler on Windows!

You can easily run out of memory, DMD is a memory hog. Yes that's exactly the problem I run into all the time. It's not even the amount of CTFE you are doing, you can run out of memory by doing something really simple. DMD is just horribly optimized in terms of memory. Yes more work for me when it's something that should be done as part of the build process.

> Try using digger - might work now that the 64 bit command line build works again.  And failing that maybe file a request on bugzilla.

For what... ?

> And I don't know but I guess if you contribute something to the D Foundation, probably - because it's still quite new - it will be easier to get people to listen to a gentle request to have a downloadable 64 bit compiler.  These things do cost money, and right now I think somebody is paying for that out of the goodness of their heart...

Everything costs money. That's how the world works. If you mean hosting the source code. Well Github hosts the source for open source projects for free. If you mean distributing binaries, well Github allows you to upload binary files for people to download for free as well. If you mean testing, well there are a lot of alternatives that provide free testing for open source projects (like appveyor which isn't currently being used). If you mean this forum board? Well there are a lot of places you have a board for free. There's some 100+ pull requests in DMD alone, just trying to contribute something is a chore in itself. Making a contribution isn't really worth much.

On Friday, 6 October 2017 at 20:17:33 UTC, Jonathan M Davis wrote:
> On Friday, October 06, 2017 17:14:51 Rion via Digitalmars-d wrote:
>> https://www.quora.com/What-is-your-review-of-D-programming-language
>>
>> It seems that D still has the GC being mentioned up to today.
>>
>> Maybe its better to move the standard library slower to a non gc version in the future...
>
> D's GC isn't going anywhere. The implementation may be improved or replaced, but there are huge advantages to having the GC (particularly with regards to memory safety), and there _are_ actually times when using a GC is faster than something like reference counting.
>
> We don't want D's standard library to rely on the GC when it doesn't need to, but there are language features that require it and really couldn't work with it, and there are cases where it's going to be involved by default for @safety reasons. For someone who wants to avoid the GC or minimize its use, there are things that they will need to do (e.g. you have to be careful with lambdas and probably use functors or functions, because closures are frequently needed when dealing with lambdas, and that means using the GC; @nogc will catch those cases for you so that you know when a lambda isn't going to work). But while it should be possible for someone to avoid the GC if they need to, that does not mean that we're looking to get rid of it or even have not using it be the default. It just means that we don't want to force its use where that doesn't make sense.
>
> Honestly, I would _hate_ to use D without a GC. Without it, @safe memory managament would not be possible, and you'd have to valgrind everything. As it stands, you only have to do that when you have sections of @trusted code that would potentially be a problem. And there's a lot of code that's cleaner for not having to worry about managing memory.
>
> That's not to say that using the GC is always better or that other solutions are not more appropriate for some circumstances - and the fact that D gives you control over a lot of that is fantastic - but this idea that GCs are always nothing but bad and should be avoided by the plague is just nonsense. GCs have their pros and cons, but they can be fantastic, and idiomatic D programs actually mitigate a lot of the downsides that you can get with a GC, because they do so much with the stack rather than the heap (which is generally better performance-wise regardless of how heap allocations are managed).
>
> Yes, we could use a better GC, but overall, the GC is really just a PR problem and not a real one. Most programs can use it and be plenty performant. And those that can't have the tools necessary to minimize its use or even outright avoid it (though honestly, if someone is looking to outright avoid it, I'd lean towards wondering what the point of using D was in the first place; the proponents of the -betterc stuff still think that it's worth it though). Plenty of folks have managed to write performant programs that involve D's GC.
>
> - Jonathan M Davis

To really compete with C++ on the same grounds, D needs a no-GC standard library, which would behave as close as possible as the GC-based standard library.

Reference-counting is used a lot in C++ game development, for resource management.

In C++, using just strong and weak pointer classes for arrays, strings and slices, you can develop programs which look like garbage collected code.