On Monday, 6 June 2016 at 22:25:34 UTC, Walter Bright wrote:
> On 6/6/2016 9:40 AM, jmh530 wrote:
>> Also, it's not like all energy will be poured into one or two of
>> them - ideally several could be worked on.
>
> Consider the recent gigantic thread on autodecoding. Is anyone working on any PRs for it?

Adam did I believe.

On Monday, 6 June 2016 at 20:28:47 UTC, poliklosio wrote:
> On Monday, 6 June 2016 at 15:06:49 UTC, Carl Vogel wrote:
>> (...) Also, the idea that more people will adopt D if you just "get rid of the GC" ignores the fact that you don't just "get rid of the GC," you replace it with another memory management scheme (manual, RAII, RC). If you replace all the parts of the language and phobos that rely on GC with, e.g., a poor implementation of RC, then you're just going to get another round of complaints, and no real adoption.
>
> I think you are going to get some adoption it you replace good GC with clunky RC.
> The key difference is a call to a function that uses GC is incomplete: some of it will execute later, after the call has finished.
> On the other hand a call to an equivalent function that uses RC has only local (in time) consequences: once you finished the call, it stopped executing. If it returned something that needs to be freed later, you know what it is.
> Of course people can write arbitrarily messed up things like singletons etc. but I'm not counting those because good libraries are usually free of those.
> This means you have control over all the OTHER code, however inefficient the call is.
> Hence, the second is acceptable in low-latency code, but the first is not.

I get that and agree. My point was a different one -- that these conversations are about a totally hypothetical RC implementation that we all imagine is perfect, and so we just discuss theoretical GC vs RC tradeoffs. The real one that gets made is going to have bugs and unexpected corner cases. So the risk is that at some point we'll all run to reddit and say "Tada, no more GC" and folks will then just say "D has RC, but it's buggy and unreliable and doesn't work when [insert anecdote]"

Maybe that won't be so---maybe the new memory management regime will be perfect and elegant and have no nasty surprises. But I feel a real "grass is greener" sense, when as many other has pointed out, the current GC could use a lot of love, which would solve problems for a lot of current users.

On Monday, 6 June 2016 at 22:07:03 UTC, Andrei Alexandrescu wrote:
> On 6/6/16 5:41 PM, Joseph Cassman wrote:
>> On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote:
>>> [...]
>>
>> Curious of the progress/plan for RC. From the autodecode thread sounds
>> like RC-string is still in the works. How's that effort coming along?
>
> Progress is slow but steady.
>
>> I
>> am guessing it may be guiding the implementation of an RC design for D.
>> If you and Andrei have a working design perhaps it could be shared (no
>> pressure, just curious since it is a tough problem to solve). Perhaps
>> sharing a plan on this front could dispel some of the negativity
>> attached to the GC?
>
> We will share things as soon as we have something worth sharing.
>
>
> Andrei

Sounds good. Look forward to it!

Joe

On Monday, 6 June 2016 at 22:25:34 UTC, Walter Bright wrote:
> Consider the recent gigantic thread on autodecoding. Is anyone working on any PRs for it?

https://github.com/dlang/phobos/pull/4394

On 6/6/2016 4:22 PM, Jack Stouffer wrote:
> On Monday, 6 June 2016 at 22:25:34 UTC, Walter Bright wrote:
>> Consider the recent gigantic thread on autodecoding. Is anyone working on any
>> PRs for it?
>
> https://github.com/dlang/phobos/pull/4394

Wonderful!

On Monday, 6 June 2016 at 21:25:07 UTC, Walter Bright wrote:
> On 6/6/2016 1:36 PM, Dave wrote:
>> On Monday, 6 June 2016 at 20:33:14 UTC, Walter Bright wrote:
>>> On 6/6/2016 12:44 PM, Satoshi wrote:
>>>> [...]
>>>
>>> More complex? Wow!
>>>
>>>
>>>> [...]
>>>
>>> C++ for junior programmers is easier? Wow!
>>>
>>>> [...]
>>
>> Most learn C++ in college. So they have a 'headstart'
>
> Even acquiring minimal competency in C++ has a very long learning curve, or perhaps I just have a different idea of what minimal competency is. Heck, the C++ code I wrote just a few years ago I regard as crap today.
>
> My personal pet peeve are junior programmers who think they get it, find some perverted corner case in the language, and build their entire application around that. They confuse their mastery of the corner case with competence.
>
> (This happens with all languages, not just C++, it's just that C++ provides so many opportunities for it!)

D is a little bit harder than most considering the lack of tutorials and the chaotic documentation that I have eluded to. Consider this:https://www.youtube.com/watch?v=c8BGQ3CfPBs

I saw this series literally the day AFTER they released Swift.

I find lots of D talks, but nothing even REMOTELY close to this. I have to fall back onto your documentation that is littered with non-useful examples and broken links.

This isn't a knock on YOUR work personally. Every time I learn a detail of this language I am pleased with the solution (maybe with a slight caveat of the GC). It's just how long it takes to figure it out and learn what is needed to do things right.

On 6/6/2016 2:16 AM, Walter Bright via Digitalmars-d wrote:
> On 6/6/2016 1:15 AM, Russel Winder via Digitalmars-d wrote:
>>> * Safety has holes and bugs.
>>
>> Then so does C, C++ and Rust, so this is just a comment made because it
>> can be made and sounds bad. Bad enough to salve the conscience of the
>> speaker as to why they are not already using D.
>
> It's pretty clear when they say that, and then continue using C++ which
> has no safety, that safety isn't the real reason.

This isn't a small problem, don't dismiss it quite that quickly.  Safety as a usable subset of D is still pretty non-existent and yet is used as a selling point.  The language still has holes -- I don't have bug report numbers, but others have reported them in the past, some closed some not.  At the library level things are far worse.  I've yet to be able to write any interesting apps with an @safe main.

Has anyone?

Later,
Brad

On Tuesday, 7 June 2016 at 00:19:27 UTC, Brad Roberts wrote:
> On 6/6/2016 2:16 AM, Walter Bright via Digitalmars-d wrote:
>> On 6/6/2016 1:15 AM, Russel Winder via Digitalmars-d wrote:
>>>> * Safety has holes and bugs.
>>>
>>> Then so does C, C++ and Rust, so this is just a comment made because it
>>> can be made and sounds bad. Bad enough to salve the conscience of the
>>> speaker as to why they are not already using D.
>>
>> It's pretty clear when they say that, and then continue using C++ which
>> has no safety, that safety isn't the real reason.
>
> This isn't a small problem, don't dismiss it quite that quickly.  Safety as a usable subset of D is still pretty non-existent and yet is used as a selling point.  The language still has holes -- I don't have bug report numbers, but others have reported them in the past, some closed some not.  At the library level things are far worse.  I've yet to be able to write any interesting apps with an @safe main.
>
> Has anyone?
>
> Later,
> Brad

My two cents on what I've read so far (in my week long pursuit of learning this language), is that D's safety system is the same old "C++" style philosophy in disguise. Sure if you follow all of the paradigms and code in an idiomatic way, you will have less bugs. But my experience is people do things less idiomatic and more idiotic.

In short, D has an opt in system. Which means it's EXTREMELY easy to opt out. Which is essentially what C++ has to. You can have a moderate amount of memory safety if you still to smart pointers and stray away from manual memory management (sure you have some things to worry about, such as cross referencing, etc), but forging a pointer is so easy. And even worse...so convenient at times.

Languages like Go, C# and Java are far better in this regard because you have to go WAAAAY out of your way to start doing silly things. You can. And you can by accident (C# has delegates that lead to a lot of leaks for instance), but in general the situation is better.

D has the features...but they are opt in. Which means people aren't gonna go out of there way. Just like in C++. Just an observation.

In other news if I had to guess I'd say @safe never was meant to be slapped on main, but to help give you reasonable guarantees of where issues are not. However, @unsafe would have probably been better (so you'd have to opt into the unsafeness) because that is greppable.

In terms of safety, I don't see how D is any different than C++. Which is why Rust is probably going to be the tool people reach for safety. But only have reaching for Go, C# and Java, because they require so much less of a learning curve.

On Monday, 6 June 2016 at 22:21:45 UTC, jmh530 wrote:
> On Monday, 6 June 2016 at 21:28:14 UTC, Walter Bright wrote:
>>
>>> The reason is that otherwise, you've just limited your apps
>>> to handling a maximum amount of $21,474,836.48.
>>
>> I wouldn't mind running into that problem :-)
>>
>
> It's really not that hard when you consider that many institutional investors wouldn't even consider investing in mutual funds with that amount under management. Vanguard has mutual funds with 100+ billion. I imagine their NAV (net asset value) calculations have to be exact to dollars/cents too.

In addition to the finance sector there are also a lot of other industries
which depends on decimals, e.g. all industries dealing with sensors and
measurements. The requirements for them (precision and scale) are
very different. There could be very small values with a lot of numbers
after the decimal separator, which needs to be exact.

Kind regards
André

On Monday, 6 June 2016 at 05:13:11 UTC, Daniel Kozak wrote:
>
> You can still unregister your critical thread from GC.

Thanks, didn't know you could do that.