chridou's comments

First thing I was thinking of when I saw the picture was: Is that Bart Simpson?

I do. I remember adding a lot of buffer time just in case I wouldn't be able to find my way. It is much more convenient now with G-Maps and other providers. I also remember how expensive the maps for the early navigation systems were and how bad they were.

Well, you somehow got me. When I mentioned the "everything F[_]ed" in my top post I thought I'd made it clear that I knew the commonalities.

And I have to admit that I find these commonalities very fascinating. I can still remember how I enjoyed applicatives and the like when I started with scalaz back then. Whether the model becomes simpler? I do not really know. I just found out for myself that I do not need this knowledge at work and that it didn't really help me to solve my daily problems. This is actually what drove me to Rust which in my perception is a nice practical "in between" (I know it also is no silver bullet).

Thank you for sharing your experience. Back then when I used Scala this was really turning me off Scala. Good that it all settled and that the Scala community can focus on the more important tasks again.

> why not use a fold/reduce in order to get as much parallelism as possible for free?

I always wondered how this would then be configured in a convenient way. I mean, there are situations where you can not just let the compiler parallelize to the max (e.g. web services).

> I suspect that the above reflects a very personal experience rather than something general.

Isn't the FP community in the Scala world at war?

> Option, Result, and Future are all both Functors (map) and Monads (and_then).

No. They are Option and Result and Future.

> You've probably used them without even knowing, because we didn't give it some weird, unlearnable category theory name.

No. I have not used them without even knowing. I have used Option, Result and Future. I do not need some meta-universe which just makes easy things more complicated by stating some laws which types must hold just for the sake of discussing them and have the one ring to rule them all.

Even though I see that these language capabilities remove restrictions I hope that HKTs and with them Functors, Monads, etc. will never make it into Rust.

The thing I like most about Rust is that it is still a practical language where I can still solve my problems in different ways and always know what will happen. I also care about the "how" and not only about the "what".

Everything being F[_]ed is what I do not need anymore.

I agree with you and would even go a bit further. Actually the word "boring" is completely misused in my opinion. It is all about choosing the right solution. This has nothing to do with things being boring or fancy. The word boring is clearly defined by a dictionaries and is subject to personal emotions. One could say the JVM is totally amazing while the other says it is dull and boring. This can not be the basis for an educated decision.

The points you mentioned are also part of the questions one has to ask for finding a suitable approach.

I think that all those who say "use boring ..." effectively want to say something else but either do not dare to do so or are otherwise unable to express their intentions. Nevertheless redefining the word "boring" is not a solution.

> However, for most people, using Rust for these purposes is absolutely not recommended.

Who are these "most people"? Can you get more specific here?

> Java/Kotlin paired with reactive streams makes these tasks super easy to read, once you get the hang of reactive streams. Also there are complexities in there, you just simply can't brush all the intricacies of network programming and multi-threading under the rug, but at least you are dealing only with the complexities that are necessary for your problem.

The text goes pretty much into detail. I do not understand where Rusts streams are more complicated than the Java/Kotlin/Scala ones? Did you ever write an application with reactive streams and got problems with the thread pool, people unknowingly blocking in combinators, etc..? I'd dare to say that these things also add complexity that is not necessary to the kind of problems you defined as "99% of ..."

> With Rust you are dealing with tons of additional complexity that doesn't matter to 99% of people & problems.

Where did you get that number from? What are "tons of additional complexity"?

> I just find it very alienating when people compare this to Python and do everyday tasks with it.

Maybe you just have not yet recognized that you can do everyday tasks with it?

> In order to have a meaningful discussion, let me expand on what I mean by "boring".

This is the problem with how boring is used. According to Wiktionary it just means "unable to engage or hold the interest". So how can this be a criteria for using a technology? Why do you redefine the word and deviate from the common meaning? What is the reason behind this? Why is it necessary that your understanding of "boring" has to be explained? It is a simple word which had a defined meaning for hundreds of years probably.

But here is my take on it: This was simply an attempt made by clever people within the industry to redefine the word so that they do not have to explicitly say what they really mean. Just call things without having a proper definition "boring". What is not boring must then be exciting. If we define boring to be good (which is actually crazy since the word itself has a negative connotation) everything exciting must be bad. Simple black/white thinking. And now we can simply call things "boring" as we like and indirectly call everything else bad.

Also it totally makes no sense to call technologies "boring" or "exciting" and thereby categorizing them for suitability. "Boring" is highly subjective. Some find Go boring, other find it to be exciting. Some find VBA boring, others experience it to be exciting. This has nothing to do with how complex, simple, fancy, hyped or old a technology is.

> To me, a boring language is one that is easy to learn, easy to read and which encourages somewhat homogenous code - through coding style and common idioms. It has few surprises and few dark corners.

Why is that boring to you? To me a language where I could easily reach a common ground with my colleagues so that we can together focus on business problems would be a very exciting language.

> Now I can understand that some people like the excitement of exploring new languages. Excitement of exploring new languages does not mean that the explored language is exciting/boring (whatever that means)

>However, asking your employer to let you use some language on a project because you find it "exciting" is a big ask.

One should only ask the employer to be allowed to use a new language if there is some benefit or if it is an experiment which will clarify whether it will be beneficial. This has nothing to do with boring/exciting.

> They may, however, be somewhat scared of "specialists" (in the sense of programmers who will insist on niche languages or niche technologies) because if you pay someone to write code, you don't want to have to search for "specialists" to maintain it or limit the size of your recruiting pool. You have an investment to manage.

True. This is where the risk parts enters the stage. It is always like this. The specialist might put you ahead of your competitors at a high risk while the generalist will keep you with the average at a low risk.

> Do you really think the choice of language is what makes a programmer brilliant or mediocre? Where did I even say this? What does talent have to do with the programming language being used?

> Then why doesn't reality agree with that view? If that were true then for every Donald Knuth, Fabrice Bellard, Jeff Dean and John Carmack there should be lots of even better programmers that do all their work in "exciting" languages. Where are they? They should be far easier to enumerate than the people who use "boring" languages?

Uh, with what view? Definitely not mine. Who says that the programming languages those people use are boring? I think you can simply choose any language and you are likely able to find 4 people who are potentially better programmers than the four mentioned. Not because they are bad or mediocre but because of the sheer amount of programmers in the world. Those four are simply famous but we have no proof/numbers on how "good" they are compared to the rest of the world.

> If you think caring about the long term value of code is "boring": try to start your own company and bet your own money.

And again. I never said this. Which definition of "boring" are you using here?

Also that sentence is dangerous. Even if caring for long term value would be boring (for some it might be exciting!) the real motivation for this is to secure previous investments which is a perfectly valid reason. Whether the way of achieving is is boring or not is completely irrelevant. And even further: If I would find an exciting(for me, since excitement is subjective) way to secure or even grow my investments I should not do it because it has to be boring? Securing investments or caring for long term value has nothing to do with whether something is boring or not.

> If you are that convinced of how "exciting" languages lead to brilliance it shouldn't be a tough choice to make

And once again. I never said this. I just said "Also we are scared of specialists and talent and want to stay mediocre" which not even mentions programming languages/technologies. I was just referring to how the word "boring" is misused and what might be the true intention behind the usage.

So in a summary: Good or bad decisions in business have nothing to do whether something is boring or not. This should never drive business decisions. But it seems like the word "boring" does.

> to have found the perfect abstraction, or ...

Didn't even know that I was writing about the perfect abstraction.

Mediocre environments are where you will not find much code of high quality even though every GoF pattern seems to have been applied. That simple code you mention requires professionals and talent. Looking for the perfect abstraction is what you find in mediocre environments.

Redis is actually a good example. It is a highly specialized tool. It might perfectly fit your needs but someone in your company might have defined mysql as boring and Redis to be not... So youl'll use mysql...

I never understood why people are looking for things which are boring and I think it is mostly employers who do. They should look for something which is good and solves their problems. I don't know how something with the attribute boring is of interest here as other attributes for a technology/PL might be much more important...

Actually they mean something different with "boring": It is just a lack of courage for simply saying "We are most conservative, do not want to move forwards and are not willing to take any risk. Also we are scared of specialists and talent and want to stay mediocre. Actually working with us is boring."

Please do not take this (Knuths statement) out of context. It is necessary read the whole text to understand this sentence. It has nothing to do with whether performance matters.