> because you simply are stating that exponential processes are going to continue.

Exponential process continuing doesn't imply "we're going to get there soon" in any way, shape or form. The desired goal can still be arbitrarily far.

> Well, the alternative is to learn an actual dozen of language

I would say that this is actually almost always preferable, for two reasons:

1. I believe it's generally good for programmers to know multiple languages, to be exposed to different ideas, ecosystems etc. This broadens worldviews, makes you think outside the box more often, etc.

2. Each of those languages will probably be better at what they do than D's subset. For example, D's GC isn't really one of the best ones out there. Its pure isn't the same thing as FP pure. Its move semantics is crap compared to Rust (probably even C++ does them better). The quality of the borrow-checking remains to be seen but frankly I'm skeptical, it'll probably follow the same pattern as the other features.

> - Pure functions: these allow you to statically guarantee that a piece of code doesn't perform any IO and is a completely deterministic function of its inputs.

Is this actually true? As far as I know D's pure isn't the same as eg. Haskell pure, it only prevents modifications of global state, but you can still touch data referenced by arguments. I haven't done much D though so I'm not sure what the semantics really are...

If the parameters to a pure function are marked immutable, then you cannot change data referenced by those arguments. It's functionally pure.

Ironically, sometimes people complain that the purity checks are too stringent :-)

One thing interesting about pure functions in D is the purity restrictions can be relaxed by using a `debug` prefix:

    pure int test(int i) {
      printf("%d\n", i); // error, printf isn't pure
      debug printf("%d\n", i); // ok
      return i;
    }

This makes it very, very handy to debug your functional code.

> but I prefer Go's culture much more

To me, Go culture is very arrogant, so much in fact that it almost reminds me of some Lispers of old.

Unfortunately similar thing can be said about Rust. However, in Rust, most of the crap seems to be comming from zealous newcommers and a loud minority, while the leadership and people involved seem relatively humble (or at least not too arrogant). In Go, OTOH, the arrogance seems to be stemming all the way from the top, judging from some talks & blogs by Pike, Cheney et al. Pike in particular seems to me to be a very arrogant, unpleasant person. I respect him very much as an engineer, but I will never like the way he speaks, promotes Go and spreads FUD about other languages.

> Go is designed to do concurrency via message passing, not shared memory.

... and yet experienced gophers will criticize newcomer's code for using channels too much and they will tell you you need to use traditional stupid shared memory approach instead of channels in many cases.

> This article deals with "big picture" aspects

Read: It's a rant and/or PR.

> The thing I love about Go is its fundamental clarity. It's very upfront and literal. I find it easy to understand what is happening in any particular bit of code.

When reading Go codebase I'm not familiar with, I'm very often having a hard time figuring which interfaces go with which structs. As in "Oh, this function accepts interface Foo, which is implemented by which structures?" and then I have go on a adventure throughout the codebase to figure out what structures go in there. Really annoying.

In a language whose intention is to be explicit and easy to read (as opposed to write) I can't understand for the life of me why the authors chose to make interface implementations implicit. It seems like a decision that pretty much only has downsides and which is contrary to the overall aim. I just don't get it.

The one reason that comes to mind is that doing it implicitly lets you use structures in terms of interfaces even when those structures come from codebases you don't control .

Suppose Bob's codebase has a structure implA that implements interface A, and you want to use in terms of its interface. If the language requires Bob to declare implA as an implementation of A, you have to persuade him to do so in his codebase. But if implicit implementation is enough, then you can just use implA directly as an A with no changes by Bob.

But yes, this is a sore point. It would be convenient to be able to declare structures as implementations of particular interfaces, even if the current implicit behavior were preserved.

> Suppose Bob's codebase has a structure implA that implements interface A, and you want to use in terms of its interface. If the language requires Bob to declare implA as an implementation of A, you have to persuade him to do so in his codebase.

Not necessarily, in some lanugages you can add an interface to type even if the type is foreign and you only control the interface. I believe this can be done in Swift, Rust, F# and quite likely some others...

Yup, and besides, Go has the unsafe (https://golang.org/pkg/unsafe/) package, which allows for basically the same sort of unsafety as Rust's unsafe.

In fact, I would say Rust is typically more safe than Go, because in Rust you can mark any code as unsafe, it doesn't necessarily have to involve unsafe pointers. For example in Rust FFI functions are typically marked unsafe even if they don't involve pointers. There's no way to do that in Go.

Another example is strings: Rust ensures that strings are always valid UTF-8 by marking any function that could break that as unsafe. OTOH in Go you strings can contain invalid UTF-8 if I recall correctly.

You don't describe what you actually want or consider 'sane'. But the answer is probably "There's no such thing" anyway, unless you're looking for Rust, which you probably aren't.

Syntax is inconsistent as described in the stack overflow link's second answer.

Input output like scanf and printf functions are annoying and don't work on what they are asked.

Too many gotchas and not for better - like understand how the underlying system works but some side effect by merely the design of language.

Including above points, my hope is that playing with pointers in a language I want should be easier and intuitive than using in C.

Could you please help? Pascal is just as much confusing when using pointers?

If you find Pascal and C equally confusing using pointers, then maybe the problem is that you find pointers confusing, not so much the language.

Pointers are not very intuitive. You have to have a clear mental picture of what you're doing, and think very carefully about each step to make sure that you're doing what you think you are. I'm not sure that any language can save you from that. C might actually be better than Pascal, though, because it does less to try to hide what you're doing from you. On the other hand, Pascal does more about trying to keep you from doing something stupid.

I must clarify that I am asking if pointers are just as much confusing in Pascal.

Thanks for the comment!

I think I would say that no, they are not quite so confusing in Pascal, because they are more limited. (At least, they were in the original Pascal. I have no experience with the more modern versions.) As a result, you couldn't do some of the things that you can do in C, which made it easier to understand the uses of pointers in existing Pascal code. (On the other hand, if you were trying to get pointers to do something in Pascal, and that thing was outside the range of what you could do with pointers in Pascal, then Pascal could be very frustrating...)

> The number of stars on GitHub is significant because most people whose opinion you’d care about are on GitHub, they wouldn’t star project that they were not interested in and there aren’t widespread fake accounts.

I am on Github and have been active in FOSS for years and yet I rarely star any projects at all, Github stars to me seem like vanity (just like likes on Facebook) indicative of perhaps hype but not of value.