> 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...
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.
> 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...
> 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.
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.
> 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.
In languages with termination analysis and dependent types, the source code _is_ the proof and it's verified by the compiler. Basically when such a program compiles, it's proved to be correct according to the specification.
Of course this still leaves space for bugs outside the program itself which still may influence it, such as bugs in the operating system or firmware or the like. Which may be prevented by having a formally verified OS too :)
But even in such a case, there might still be hardware errors (electrical noise, for example). Which is why for example spacecrafts or critical industry machinery double or triple their whole architectures. In such case the formally verified software runs on eg. three instances simulatenously and these instances cross-check each other's results all the time. When a hardware fault occurs (a bit randomly flipped in memory for example), they find out they're not matching and re-calculate.
> Sure, you can’t in the general abstract case, but my exact point is that you can do this in practice, for programs which we actually write.
No, it can't be done with testing even for practical everyday programs, precisely because you never know how much your program is crossing into the "abstract general case" and which parts of it are more general than you think. Very often the cause of bugs is precisely this - that some part of a program behaves in a more general / less restricted way than the programmer thought.
It can be done with formal verification, but that's a whole another story.
> The previous poster is correct. Software cannot be proven to be bug-free.
Yes, it can, that's what the whole formally verified software branch is about. Of course, even with formally verified software, there can be failures caused by external factors such as faults in hardware etc. But some piece of software itself absolutely can be proved to be correct (ie. bug-free). It just takes special approaches such as programming languages amenable to formal proofs (eg. Idris).
Software is usually written in bug-inducing ways and using languages that hinder formal verification not because provably bug-free software is impossible but because it is typically too costly and difficult to write.
I never said people didn't like Spotify or Slack. In fact, I said the exact opposite. Please read the comment properly and try to understand, don't just skim checking for "the right" opinion.
The thing about Electron - and the thing that Electron fanboys either don't realize or don't care - is that with Electron, the company/vendor wins at the expense of users, who have to put up with their "application". No one really likes Elecrton apart from the vendor/developer and the most fanatic fanboys. Everyone else at best doesn't mind Electron.
If an Electron "application" is decent, people typically like the features or the online service to which it's tied but its Electron base is something that people more or less tolerate, depending on the degree it irks them. It's just a huge tradeoff, that's all. It reminds me of some Java or Python desktop applications, it's a similar kind of tradeoff.
> Hey can you give what is the rationale behind the JS hate?
JS has its overhead in terms of data and, more severly, performance. Many people tend to put unecessary JS stuff like custom scrolling, needless animations and needless interactivity, etc. This stuff more often than not just ends up getting in the way of normal browser function and is of questionable benefit or none at all.
> I am building a website that relies heavily on JS. What should I be aware to steer away from the JS hate?
Don't add any JS interactivity that only makes a website "look cooler"* and that's not actually critical to your website's functioning. For example, stuff like google maps needs javascript. Stuff like blog most likely doesn't.
Remember to try out how your website works on a device with weak hardware and slow connection. This will not only make it far more accessible for people with older hardware, it will make better for recent hardware as well.
*) today's expression would probably be "rich user experince" or somesuch, but the meaning is the same - it's just vanity
> But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way.
Yes, I agree, but that's not the full picture. People want a language in which they can be productive quickly, but once they master it, they, or at least some of them, will then look into quality and performance. Languages like JavaScript or Python (and even Go to some extent) are popular and easy to pick up, but there's not much room for further progress. JavaScript is already stretched to its absolute limits when it comes to performance and it's still not performing very well. And when it comes to quality, well, TypeScript is a thing for a reason.
I don't believe Rust will ever be as much of a language for the masses as JS, but it has a good chance to become a niche language for those who need or want more performance and/or quality than they can get with langs like JS or Python.
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.