On Tuesday, 7 June 2016 at 09:29:35 UTC, Russel Winder wrote:
> That is the current state after 7 years of development, and at least three GCs. The arguments about GCs in the Go mailing list were almost similar to those in these D mailing lists.

It probably was. I only followed those mailing lists when Go was first launched and people didn't complain then, but they complained about lacking exceptions and non-null pointers.

I knew Go users complained about GC performance after some time (when trying to use it in production), but I didn't know they complained about having a GC?

> However it is, and always has been, emphasized as a systems programming language. Their "strap line" is effectively that GC is not a problem for systems programming. And they are right.

They initially said it was a systems programming language, but they later turned around and said it isn't and isn't trying to be. Go is a high level language, it does not try to give unbiased access to hardware semantics. So it cannot be considered a system level language. I am not even sure if Rust fully qualifies atm.


> Which is why D has no problem with being a GC language.

Well... that remains unproven. :-) And I don't agree.

> If C++ and Rust can only offer 20% improvement they are dead in the water.

I meant that by not having a GC C++ can get approx 20% improvement over Go with the same code as the Go code by writing idiomatic. There is also overhead when making system calls and also C-calls in Go, thanks to the GC.

That said, in the cloud it makes a lot of sense to not use a system level language and use a high level "virtual" environment so that you can upgrade hardware without affecting the behaviour of services.

If Go was positioned as a system level language it would be dead.


> I would love to create a CSP thing for D but I cannot give the time to do this on my own.

I don't use CSP in Go... The only thing I care about regarding Go is: high level (not particularly hardware dependent), GC, http, significantly faster than Python for web-servers, AppEngine support and good searchable online documentation (traction).

If Go was a system level language I would not consider using it actually and I am only starting to adopt it, very very slowly, as Python still have many advantages over Go in production. I am never going to use Go for something I couldn't do with Python.

So to me C++ and Go have disjunct application areas. Rust and D mostly are in the C++ domain, with a little bit more overlap with Go than C++, but not much.

That said, if the basic simplicity-oriented design philosophy in D1 had been refined, then D could have taken on Go. As it stands, I don't think D can without making very radical  changes to the language.

On Tuesday, 7 June 2016 at 09:49:34 UTC, Russel Winder wrote:
> std::unique_ptr and std::shared_ptr maybe great for those who have to use C++, but for those with a choice it is the fastest route to Rust. And then you find Rust cannot cope nicely with many C libraries. Hence you find your way to D. Only to find to developer environments nowhere near as good.

Well, currently C++17 has overall better semantics than Rust and D, for system level programming.

It is just a very expensive language to become and remain proficient in, and C++ syntax issues means you have to spend more effort on making your code maintainable... :-/

Both Rust and D have syntax and semantic issues, if they had focused on improving the ergonomics instead of adding features then they could take on C++. As it stands, they cannot.

So yes, and top notch editor is needed to gain ground, but isn't sufficient as of today.


> For a traditional Emacs person, I am finding CLion a joy to use. D needs equivalents.

Good static typing based editors matter _a  lot_. My own experience is that PyCharm makes it harder to justify using a statically typed language over Python. So Python benefits enormously from PyCharm being available in a community edition.

It is quite interesting that editors can add missing language features like that and turn dynamic languages into gradually typed languages (more or less).

On Tuesday, 7 June 2016 at 09:11:38 UTC, Ola Fosheim Grøstad wrote:
> Try tell someone making a 3D engine that your tooling is used in banking and that they should switch from C++.
>
> Now, don't feel insulted, but banking/finance is considered a boring application area by most programmers I know of.

And yet, the financial/banking sector loves game/engine programmers because they give a damn about real-time performance. There are plenty of ex-game-developers in that sector making three times as much money as they used to.

Not to say that it isn't boring. That's purely a subjective thing.

I just noticed you [i.e. Brad] had made some bugzilla entries about @safe that were not tagged with the 'safe' keyword. I have gone ahead and tagged them, so now:

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe&keywords_type=allwords&list_id=208819&query_format=advanced

should be a more or less complete list. If there are more, please add.

On Monday, 6 June 2016 at 20:19:20 UTC, Observer wrote:
> On Monday, 6 June 2016 at 19:55:53 UTC, DLearner wrote:
>> If we allow _int foo;_ to declare an integer variable foo, then suggest we have
>> _dec bar(a,b);_ to declare a decimal variable bar with a units in total length, b units of decimal places.
>> D language then defines how (for example) assignment is carried out (by default), and also provides mechanisms for alternatives (ie some sort of dec_trunc() and dec_round() functions).
>
> And when real-world money is involved, you'd better have arithmetic
> overflow trigger an exception, not just wrap around silently.

I made an abstraction, which uses long internally. If the value range is big enough, it works fine.

http://code.dlang.org/packages/money

On Monday, 6 June 2016 at 09:16:45 UTC, Walter Bright wrote:
> Paying attention to our existing users is a much more reliable source of information.

+1000

On Tuesday, 7 June 2016 at 10:28:37 UTC, Ethan Watson wrote:
> performance. There are plenty of ex-game-developers in that sector making three times as much money as they used to.

I am sure there is, game programmers/smaller companies also contribute a lot of libraries and knowhow (tutorials etc). Whereas the suits in games are in it for the money, I think most game programmers are in it for other more "idealistic" reasons. The difference between:

1. Programming in order to reach some non-software performance goal.

2. Programming in order to achieve a programming related esthetic result.

Attracting the culture in group 2 is much more valuable to a community project as they find it meaningful to share their knowledge (games, raytracing, compilers etc). It isn't only a job then.


> Not to say that it isn't boring. That's purely a subjective thing.

I don't know if it is boring or not, probably depends on where you work, but the reputation isn't very marketable. Unlike say embedded programming.

Embedded programming -> excellent hardware access / memory usage
Games programming -> excellent access to OS APIs and resource management

On Tue, 2016-06-07 at 09:55 +0000, ketmar via Digitalmars-d wrote:
> 
[…]
> considering that the whole package, including dlangUI, is one man work... give it a chance! ;-)

A project starting as a one person thing is quite natural, a project aiming to gain traction remaining a one person project is a dead end siding.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 7 June 2016 at 11:11:31 UTC, Russel Winder wrote:
> On Tue, 2016-06-07 at 09:55 +0000, ketmar via Digitalmars-d wrote:
>> 
> […]
>> considering that the whole package, including dlangUI, is one man work... give it a chance! ;-)
>
> A project starting as a one person thing is quite natural, a project aiming to gain traction remaining a one person project is a dead end siding.

not everybody is good at promoting their work. yes, this skill is required to make your project wide-known (and then wide-used), but... this is where other people can step in to help. i'm sux in promoting things too, so i'm doing as much as i can: mentioning the project occasionally here and there.

On 6/7/16 4:05 AM, Russel Winder via Digitalmars-d wrote:
> On Mon, 2016-06-06 at 16:56 +0000, Wyatt via Digitalmars-d wrote:
>> On Monday, 6 June 2016 at 14:27:52 UTC, Steven Schveighoffer
>> wrote:
>>> I agree. It's telling that nearly all real-world examples we've
>>> seen (sociomantic, remedy games, etc.) use D without GC or with
>>> specialized handling of GC.
>>
>> I doubt either of the two you named would change, but I wonder
>> how different the tenor of conversation would be in general if
>> D's GC wasn't a ponderous relic?
>
> So instead of debating this endlessly, I think this is about the tenth
> time this has come up in the last two years, why doesn't a group of
> people who know about GC algorithms get together and write a new one?

People have. Reiner wrote a precise scanning GC. Leandro wrote a forking GC that is used in Sociomantic's software. Martin has made some huge improvements to the existing GC for performance.

I think there is some difficulty taking a new GC and putting it into druntime. We druntime developers take for granted many times how the GC is implemented, without considering the ability to swap it out.

Let's also not forget that the GC is a super-integral part of the runtime, and it deals with one of the most difficult-to-debug aspects - memory allocation. If you replace the GC, you better have it perfect.

From my experience replacing the D array runtime, it is a very very difficult thing to debug and get right, the bugs are disastrous and difficult to trace and reproduce.

Not to say we shouldn't do it, I think we should at LEAST have it optional (like with globally recognized runtime parameters: --usegc myfavoritegc). But I don't want to act like GC improvement is something nobody has ever looked at.

My opinion, the first optional one to include is the forking GC, since it has been in production for years for one company. We may even find some bugs in it to help out Sociomantic, since they have discovered and helped fix so many problems with D :)

If we have the ability to swap out GCs, then it makes it easier to define how the GC API must work.

-Steve