EvenThisAcronym

> We merged the tuple destructuring PR (that was open for years again so the author was happy to get it to land somewhere!) and upstream followed there too.

FYI that had very little to do with OpenD merging the tuple syntax - at least from my perspective - Timon may feel differently. I was the one who got the ball rolling on the DIP for it and kept pushing the process forward, and I also helped Timon and Nick get it over the finish line by fixing an ICE in the backend caused by destructuring a tuple of structs.

I've wanted first class tuple syntax in D since 2013, and when Timon mentioned not having time to do a DIP for it, I offered to help. It would've happened regardless of whether it got merged into OpenD or not.

I think the cognitive function model is fine and useful, which is why Dr. John Beebe's model is so appealing.

My main issue with Meyers-Briggs is the use of a questionnaire to type people - I'm an ESFP, but every time I've taken an MBTI test I've gotten back INTJ or ISTP. I never felt that either of those were completely accurate, or that I was an introvert. It's far, far more accurate to type people based on their preferred styles of interaction and thinking (e.g., as an ESFP I have an informative, initiating, movement-based interaction style and I think in concrete, pragmatic, interest-based terms).

Meyers-Briggs is absolute trash and should not be used by companies for anything. Big 5 is also almost completely worthless beyond vaguely describing a person's general tendencies.

The only system that seems to have any sort of validity and real-world use is Dr. John Beebe's Eight-Function Model.

> The problem with all-chat in League of Legends, particularly in the ranked queue, is that it can only hurt your team's chances to win. At best, you're wasting time typing; at worst, you're actively frustrating and distracting yourself from what is already a very difficult game.

I don't agree; /all is a very viable vector for giving your team a huge leg up. If you are skilled at talking shit, you can usually tilt someone on the other team so much that they become a non-factor. So many times I've seen the enemy team turn on each-other because one of their laners made some small mistake, which I capitalized on as a chance to relentlessly attack them in /all chat. They become tilted and start playing poorly, their team starts attacking them as well for the poor play, and often they will either troll, constantly call for a surrender, or even AFK in the fountain. The mental aspect of the game is just another tool in your arsenal for gaining an advantage over the enemy, and in my opinion it's just as important as the mechanical and strategic aspects.

> As just one anecdote, the mere presence of a GC made me stop looking at D more or less immediately.

That's a shame, because it is extremely easy to write GC-free code in D. One very important fact is that if you don't allocate using the GC (using "new", appending to a slice, etc.), *the GC will never run*. D provides you a ton of tools to make sure that you're not doing GC allocations, and if you are, where in your code they are happening (@nogc, -vgc and even -betterC).

> But it also seems like D is not suitable for a lot of things that C++ is, like embedded applications

Not sure where you got this idea, as being usable for embedded programming is explicitly one of D's design goals. You can use D anywhere you use C++, and it is a much nicer language to boot!

> Also, it doesn't seem like support for Android and iOS is very good at the moment

I can't comment on this. There is support for both platforms IIRC, but I haven't tried writing apps for either in D.

> But I'm hesitant to build anything with it because as much as I loathe working in C++, it's still the safest bet by far.

I'm not sure what you mean by "safe" here. D has been around for over 20 years and isn't going anywhere anytime soon. The main difference from C++ is that the community is smaller, and it's a bit harder to get a job writing D (but not that much harder nowadays; there are a lot of people working for companies like Symmetry Investments, writing D every day).

> Also, Swift seems like it has similar goals, but with Apple's full support behind it.

Swift also seems like a very nice language, and I would probably be using it if D didn't exist. That being said, its metaprogramming capabilities are woefully underpowered to D's. From my experience, only the Lisp family of languages beat D in this area.

> Rust has Non-Lexical-Lifetimes (and soon Polonius). D's documentation is very sparse about how lifetimes in @live will be determined, but I think it's safe to assume that it will be scope-based at first.

@live also has non-lexical lifetimes: https://forum.dlang.org/post/[email protected]

> I couldn't sleep much (sometimes 4 hours max) Did you find some way to mitigate this or did you just have to live with it during the fast?

> Exercising might reduce the loss of muscle mass to some extent

That does indeed seem to be the case, at least for a 16:8 intermittent fasting regimen (an 8 hour eating window with 16 hours of fasting): https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5064803/

"Our results suggest that an intermittent fasting program in which all calories are consumed in an 8-h window each day, in conjunction with resistance training, could improve some health-related biomarkers, decrease fat mass, and maintain muscle mass in resistance-trained males."

Then use garbage collection; it's an easy default.

>If you need typed functional programming, your options are OCaml, Scala, F# or even subsets of Rust and TypeScript.

And don't forget D. It's surprisingly well-suited for FP as its effects system has explicit support for pure functions and specifying a function is guaranteed not to throw, in addition to support for true (transitive) immutability. Not to mention full first-class function support, with lexical closures.

> However I MUST say this is from 4chan so BE CAREFUL about what you download and how you play with stuff.

The only danger in downloading something leaked on 4chan is that you run the risk of learning a little more about dolphins than you might have liked.

Rust does have auto; "let" and function literal parameter type inference, for a start. It just doesn't let you use it in the return type position.

Returns

A range with each fun applied to all the elements. If there is more than one fun, the element type will be Tuple containing one element for each fun.

We already have this for food: services like Skip The Dishes, Uber Eats, etc.

> Profit is not compensation for risk.

Yes it is. The primary reason anyone takes on risk is because there is profit in it.

Visual Studio with Visual D is a top notch D experience.

> So what am I missing here?

The Haskell program is multi-threaded (I don't know about wc's official implementation, but I assume it is as well), while the D program is single-threaded.

> Rust came to be to address the issue with security and there is not really an alternative.

What does Rust have to do with security? It's not even compliant with any modern security standards (at least not that I'm aware of).

> I have no idea what I would use D for.

This makes no sense. D is a general-purpose language, just like Rust, Nim and Go (and it does concurrency better than Go, IMO). It just happens to be the best general-purpose language that I've ever used. The language gets out of your way and lets you focus on solving problems in the domain you're working in.

Yes, or if you don't want to use a template function, for whatever reason, you can wrap the result of iota(1000) into an InputRangeObject (see https://dlang.org/phobos/std_range_interfaces.html#InputRang... for an example).

> I don't like how the conditions are detached from type definitions

I can understand that; it's something that takes a bit of getting used to. See https://dlang.org/concepts.html for an explanation of template constraints and why they were designed this way.

Visual D with Visual Studio is the gold standard, with full debugging, autocomplete, and static analysis support.

Code-D with VS Code is also great, and it has fairly recently gotten funding from the D Language Foundation for further development.

There's also DCD, D-Scanner and dfmt which can be used with a lot of different editors.

Let me give you a little guidance on this (if you happen to still be using D). Most functions in std.algorithm (and many more throughout the rest of the standard library) return "ranges", which is like a begin iterator and an end iterator zipped up into one data structure. There is a "range hierarchy" that mirrors the C++ iterator hierarchy:

Input/Output Range > Forward Range > Bidirectional Range > Random Access Range

Input ranges provide the following API:

    bool empty()
    T front()
    void popFront()

Forward ranges provide the same API, and also add a "save" function that creates a copy of the range's current state.

Bidirectional ranges add "back" and "popBack" functions, which don't really need any explanation.

Random access ranges additionally add a "length" function and constant-time array-like indexing.

In addition to most functions in std.algorithm _returning_ ranges, most of them also _accept_ ranges. Therefore, you can freely pass the result of any function in std.algorithm into another function that takes a range, and it should all just work. It's pretty much the same deal as in Rust/Java/Swift/etc. with their various iterator protocols, although the API for ranges in D is more influenced by C++.

For example, the first Project Euler problem, using a range-based approach:

    import std.algorithm;
    import std.range;
    import std.stdio;

    void main()
    {
        //List all the natural numbers below 1000 that are multiples of 3 or 5
        auto natsBelow1000 = iota(1000); //iota returns a range that lazily computes the numbers from 0-999
        auto multiplesOf3Or5 = natsBelow1000.filter!(n => n % 3 == 0 || n % 5 == 0); //filter accepts a range as an argument, which it lazily filters according to the given predicate
        auto sum = multiplesOf3Or5.sum(); //Sum accepts a range of "summable" items and computes the... sum
        writeln(sum); //Prints 233168
    }

A D programmer wouldn't generally write things this way, preferring to make a more idiomatic "range chain" like you'd see with Java's streams or Rust's iterators, but you get the idea.

As you might have guessed, arrays are also ranges - random access ranges - which is why they're so easy to use.

I would highly recommend against putting `.array` everywhere in your code, as it will force the range you pass to it to be eagerly evaluated and allocate more memory from the GC. It's much better to take some initial data store, like an array, do all your filtering and mapping, etc. on it, and when you're done, _then_ turn it back into an array with a call to `.array`. That way you'll get all the lazy iteration and low memory footprint of ranges, and then at the end you have a nicely allocated array of data with the result that is easy to work with.

Honestly, though, in most of my code I usually just pass around ranges as they're very good for creating interlocking adapters over different backing stores. One really great article on advanced usage of ranges is H. S. Teoh's article on Component Programming with Ranges: https://wiki.dlang.org/Component_programming_with_ranges

A couple great resources on ranges in D:

http://www.informit.com/articles/printerfriendly/1407357

https://tour.dlang.org/tour/en/basics/ranges

http://ddili.org/ders/d.en/ranges.html

http://dconf.org/2015/talks/davis.html

> This is different from being able to walk a directory and read random files.

D doesn't allow you to do that either. You have to specify what files you are importing via a compiler switch: https://dlang.org/spec/expression.html#import_expressions

> D's contract mechanism [...] can provide very strong guarantees to the compiler... which the LLVM D compiler definitely uses.

That's awesome. I didn't know LDC uses contracts like that. It'd be nice to have similar functionality across all D compilers.

- D: lightning fast dev time; fast compile times; performance directly comparable to C and C++; metaprogramming capabilities second only to Lisp.

Yes, thanks. Forgot to actually post the link.

> Tangentially it’s not clear to me what relevance D should have for any greenfield projects where there is not already heavy investment in a code base to consider.

Another one of Cybershadow's articles on D that blew my mind is, IMO, one of the greatest arguments for why you should care about D. The beauty, conciseness and flexibility of the implementation here is extremely cool. And this is not a one-off case; there are many programmers in the D community that create awesome stuff like this all the time. Writing in D is like having superpowers, and going back to a less expressive language feels horribly constraining.

I'm not disputing that, just providing a data point that you can still live in Canada and work as a dev for good pay and a low cost of living. I could move to the US and make twice my current salary, but that comes with its own drawbacks.

>"don't pay very well." is a key point in Canada.

You say that, and it's probably true on average, but I'm making 33% above the average salary for my province. Granted, I don't live in one of the "big" provinces and competition for tech jobs is not as high as it would be in hotspots like Vancouver/Toronto/Ottawa/Montreal.

Granted, I'm making less than an equivalent job in one of the big tech hubs in Canada, but the cost of living is a fraction of what it is in the bigger cities as well.

There's a strictly adhered to rule across Reddit/HN that every D article must consist primarily of people asking why the author did not use Rust/Go instead.