On Tuesday, 7 June 2016 at 19:07:03 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 7 June 2016 at 18:59:13 UTC, ketmar wrote:
>> side note: garbage-collected OS is possible, and written, and is working. Inferno.
>
> Yes, the Go guys was involved. So it is possible yes, but why would you want to have a garbage collected kernel? What do you gain from it? Extra trouble is what you gain from it.

I also 'never' claimed it wasn't possible. Nor that you couldn't do it in Go. However, should you...I'm not that convinced it's a good tool for the job.

On 6/7/2016 11:36 AM, Timon Gehr wrote:
> You didn't find it because it was closed by Walter for no good reason about 10
> hours ago.

If you want to make a DIP out of it, please do so. It was inappropriate as a bugzilla issue.

On Tuesday, 7 June 2016 at 19:16:13 UTC, ketmar wrote:
> 'cause it simplifies memory management, on all levels... if we'll switch to microkernel architecture. but this is very off-topic.

Inferno was a MMU-less VM like JVM, but failed miserably to gain traction... In a micro kernel design all services are moved to user-space and the privileged kernel is minimal, which suggests no benefits from GC. Yeah, OT. Except it does reflect the Go authors preference for weird-and-pointless solutions. Just like Go's desperate attempt to avoid adding exceptions: panic-defer-recover, a weird hack that is possible, but not something that would make anyone satisfied. There are more hacks like that in Go, like Ds growing slices that suddenly reallocates behind the scenes.  They seem to follow the guideline «it is possible, and kind of simplistic, therefore it is a good idea», but they are wrong. Go is a mixed bag.

On Tuesday, 7 June 2016 at 19:29:11 UTC, Dave wrote:
> I also 'never' claimed it wasn't possible. Nor that you couldn't do it in Go. However, should you...I'm not that convinced it's a good tool for the job.

That's right. It isn't. I think the ones looking at Go, just wanted to use it as a simple starting point and planned to strip out the GC. I don't know why they didn't want to write their OS in C, maybe they wanted to add some semantic analysis that isn't possible in C as part of their research. I just thought the request was very odd:

https://groups.google.com/forum/#!topic/golang-nuts/6dI4vIxRgn8/discussion

On 6/7/2016 11:32 AM, Adam D. Ruppe wrote:
> On Tuesday, 7 June 2016 at 18:24:33 UTC, Walter Bright wrote:
>> You can also add:
>>
>>    @nogc:
>>
>> at the top, too. It isn't necessary to tediously annotate every function.
>
> @nogc:
>
> struct Foo {
>         int* a() { return new int; }
> }
>

You're right, the global @nogc doesn't go through the struct. But @safe does.

On 6/7/2016 11:32 AM, Timon Gehr wrote:
> The @safe subset should be specified and
> implemented by inclusion, such that it is obvious that it does the right thing.
> I don't know what's 'unspecific' about this.
> Closing holes one-by-one is not the
> right approach here. You don't know when you are done and might never be.

I don't see how it is any different painting the fence from one direction or the other. There are omissions possible either way.

Another issue is implementing such a spec. The "disapproved" list is how the compiler works, and makes it reasonably straightforward to check the implementation against the list. It's quite a mess to try to tag everything the compiler does with approved/disapproved, so you wind up in exactly the same boat anyway.

In any case, writing such a large specification covering every semantic action of the of the language is way, way beyond being a bugzilla issue.

If you want to take charge of writing such a specification DIP, please do so.

On Tuesday, 7 June 2016 at 16:12:42 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 7 June 2016 at 15:15:03 UTC, Chris wrote:
>> Features are important. Templates, for example, make writing code in general and libraries in particular much easier.
>
> Both C++ and D have simple macro-like duck-typing templates. I don't find that approach particularly impressive. Yes, I use it a lot, but templated programming in this fashion also easily get convoluted and having multiple levels of abstraction can reduce transparency and make debugging more difficult.

But we agree that templates are a good idea in general, regardless of the actual implementation.

>> You sound as if a wealth of features and good libraries were mutually exclusive. They are not. The problems with Phobos are not due to D's features but to a specific implementation (slow algorithms) - like in any other language.
>
> Well, D has some language features that probably should be library features (like slices) and some library features that should have been language features (like memory management).

What do you mean by `memory management`? GC/RC built into the compiler?

> However I was not complaining about "problems", but pointing out that system library APIs get out-of-date over time irrespective of the quality of the implementation. The more detached library features are from the core language the more likely they are to get out-dated.
>

What do you mean? Is it a good or a bad thing that the library is detached from the core language?

>> When writing software, it's important to have a wealth of features to choose from so you can use the one that best fits the task at hand.
>
> Not really.
>
> C++/D would have been better languages if they just cut all the pointless special casing and boiled the core semantics down to templates and functors.
>
> C++ has at least boiled lambdas down to functors and are better for it.

Believe me, features will be requested. Would you have an example of how such a language, or better still did you have time to design and test one? A proof of concept.

>
>> You realize that when you have to use a language with less features, then it's repeat yourself, repeat yourself ...
>
> Not true in my experience. Which languages have you used? Orthogonal minimalistic languages can be very expressive. Actually, it is often the opposite, because without that minimalism you have to special case a lot of stuff when similar entities cannot be treated the same.
>
> However in some minimalistic languages everything looks the same (like Lisp) which can make it harder to read source code. Sometimes you want a DSL for readability. However I don't think C++ or D score high on readability. It is not their core strength.
>
> I don't find C++ std or Phobos particularly readable. I can read it, but neither provide shining examples of legible code.

Having to write the same for loop with slight variations all over again is not my definition of efficient programming. One of D's strengths is that it offers nice abstractions for data representation.

>> Java has lambdas now (since version 8, I think) and I read somewhere that it's not certain that Java programmers will adopt (i.e. use) them at all.
>
> So, Java was designed to be a simple language, just like the JVM is simple. Lambdas aren't anything special. Most languages have anonymous functions. Even the minimalistic OO ones.

Not special but handy. Before Java 8 (?) you had to use inner/anonymous classes to mimic lambdas. Not very efficient. Boiler plate, repetition, the whole lot.

>> D has the advantage that its users are not so complacent and actually demand and welcome new features and happily use them. They're not lulled into believing that this or that feature is useless.
>
> Uhm... Do you really think this reflects reality? You mean the D language designers and fanbois don't try to cut people down when they point out where D needs improvement? ORLY???

I was not talking about that. Read it again. I said that the D community actively demands features or improvements and uses them. What you refer to has nothing to do with my point and it doesn't happen very often on this forum. Usually everything is discussed to death and beyond.

>> This is why D evolves somewhat faster which helps to attract users who look for something different, who are not happy with the status quo.
>
> But it doesn't evolve much, it adds features without fixing what is already there. Which makes it harder and harder to make any significant progress on the language semantics.

That's how it works. Add, test, improve. Having to wait for years for a feature is terrible, because you build up a code base with code that is not optimal and verbose (cf. Java). It goes without saying that existing features have to be improved. It's a question of manpower.

> C++ actually do improve on the existing features, lambdas was improved in C++14 and further improved in C++17 (constexpr). And C++'s take on lambdas is better than D lambdas. Despite C++ not being able to push breaking changes, which D can (D's major advantage over C++).
>
> If D improved on the existing feature set then it could stand a chance. Like, it could provide better integer semantics than C/C++, but chose not to. It could provide better floating point semantics than C/C++ (not hard to beat, as gcc/clang messes up rounding modes), but chose to stick with something even worse. The only advantage D has in the template department is the ability to select class-members using meta-programming. Everything else you need for practical meta-programming can be done just as well in C++.
>
> If you compare current day D to C++ it only have two advantage points:
>
> - static if
>
> - a naive garbage collector
>
> But D lambdas are worse, floats are worse, ints are worse, simd support is worse (gcc/clang) and documentation is worse.
>
> Please understand that I am not saying that C++ is really great, but D is deliberately not trying to be better, but for some reason choose to just be "somewhat different". That cannot work out to D's advantage as both languages have too many pitfalls to be suitable for newbies (in comparison to high level languages).

There is a learning curve that cannot be made flatter. There are concepts that have to be grasped and understood. Any language (cf. Nim) that allows you to do sophisticated and low-level things is harder to learn than JS or Python.

> As such, Go is better than C++ in some domains by being dependent on GC and stripping down features to the essentials. Go is very unexciting, but they stuck to improving on some core competitive features over time. Which paid off in that niche as other languages cannot get those features within 3 years.
>
> D needs to improve too. Not by growing the feature set, but by improving on what is already there.

Go forces you to repeat yourself. The less features you have, the more you have to write the same type of code all over again. Look at all the for loops in a C program.

On 6/7/16 3:44 PM, Walter Bright wrote:
> On 6/7/2016 11:32 AM, Adam D. Ruppe wrote:
>> On Tuesday, 7 June 2016 at 18:24:33 UTC, Walter Bright wrote:
>>> You can also add:
>>>
>>>    @nogc:
>>>
>>> at the top, too. It isn't necessary to tediously annotate every
>>> function.
>>
>> @nogc:
>>
>> struct Foo {
>>         int* a() { return new int; }
>> }
>>
>
> You're right, the global @nogc doesn't go through the struct. But @safe
> does.

Bug? I would have expected @nogc: to permeate.

-Steve

On Tuesday, 7 June 2016 at 17:19:16 UTC, Wyatt wrote:
> On Tuesday, 7 June 2016 at 08:05:58 UTC, Russel Winder wrote:
>> 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?
>
> In addition to the other answers, it's worth noting that most every good modern GC algorithm I can think of requires barriers.  Walter has repeatedly and emphatically declared that D will not have barriers, so we're kind of SoL on on that front.  Java and Go don't have that problem.

Barriers are only necessary if you want a low-latency or concurrent GC, afaik. I'm not sure if low-latency is worthwhile for D. If latency is important, you might be better off to disable the GC (partially). Concurrent is nice for servers, where you do not care about memory consumption.

D does not even have a precise GC so far and that fruit hangs much lower. It is a precondition on basically any advanced GC techniques.

On 6/7/2016 12:52 PM, Walter Bright via Digitalmars-d wrote:
> On 6/7/2016 11:32 AM, Timon Gehr wrote:
>> The @safe subset should be specified and
>> implemented by inclusion, such that it is obvious that it does the
>> right thing.
>> I don't know what's 'unspecific' about this.
>> Closing holes one-by-one is not the
>> right approach here. You don't know when you are done and might never be.
>
> I don't see how it is any different painting the fence from one
> direction or the other. There are omissions possible either way.

Yes, either direction has the probability of being incomplete.  However, when the disallow by default and allow only explicitly activities is _far_ more correct in the face of omissions.  In the case of an omission of something that should be allowed, you haven't discovered a violation of safety, you've discovered a place to allow additional safe code.

To use an analogy, would you trust a security model where the list of people not allowed to withdraw from your bank account be a whitelist or a blacklist?

> Another issue is implementing such a spec. The "disapproved" list is how
> the compiler works, and makes it reasonably straightforward to check the
> implementation against the list. It's quite a mess to try to tag
> everything the compiler does with approved/disapproved, so you wind up
> in exactly the same boat anyway.
>
> In any case, writing such a large specification covering every semantic
> action of the of the language is way, way beyond being a bugzilla issue.

Yes, it's hard to implement.  Shrug, you signed up for it.