olavk

If you only write code which you yourself will read and maintain, then you should definitely do whatever you feel works best for you and matches your way of thinking.

Well written code is obviously better than badly written code. But why assume the functional-style is better written than the idiomatic Python? I think a good developer understand the context they work in rather than try to fit a square peg in a round hole.

I wouldn't like to maintain Haskell code written by someone who thinks everything should look like Python. And vice-versa.

I believe it started as a way to model real-world object. Simula was designed for simulations. But OO turned out to be useful for much more. The simulation use case mostly live on in tutorial and examples, spreading confusion to beginners.

But I also think the "message passing" metaphor has outlived its usefulness the same way. A caller does not need to know how the callee is implemented. Sure, but this is the same in any language with functions/procedure, this is not something specific for OO. The idea of message passing is a bit deeper, for example that the client does not even know it is calling a method. It sends a message, and the object answers, even if it is just by throwing an error that the message is not supported. This is how Smalltalk and (I think) Ruby works, but not at all how a statically types language like C# works. And it is not how Python works either. In Python you obtain a method reference from an object and then invoke it. So if you apply the message passing metaphor, your are actually passing the message to the method rather than the object itself. Which I think is just a confusing way to describe a method call.

I like removing superfluous punctuation, but if parentheses are removed from method signatures than they should also be removed from invocations, which in turn comes with its own set of readability issues. I'm not a fan of the $ operator in Haskell, for example.

Haskell does not have borrowing and lifetime specifiers though, which is what makes the Rust example more dense.

It is somewhat unfair to compare this to Python, since a lot of the simplicity in Python comes from the semantics (dynamically typed, garbage collected and so on). Rust need to express all this information (types, lifetimes etc.), so it will necessarily be more dense. The question is if this information could be expressed in a more readable syntax. This might be possible, but I would like to see a suggestion of how.

I guess the signature could be made more readable by using a few type aliases. The hardest part to read is the nested types.

I'm with you on the macro syntax, it is very hard to read. It is not easy to create a readable macro syntax though. All languages I know have hard-to-read macros, so this is not yet a solved problem.

What editor does not support indenting a block? In most editors I know you select the block and hit tab, or shift-tab to outdent.

So again a pet hypothesis which can explain both rising and falling IQ. So what observation could theoretically disprove this hypothesis?

Note that you can state exactly the opposite hypothesis and still claim the numbers support it. The use of gaming consoles and smartphones improve IQ, but this effect have maxed out in Scandinavia.

> The roman civilization used lead pipes for drinking water.

True, but the theory that this affected public health is a myth.

Amazing that the same pet hypothesis can explain both rising and falling IQ.

So why is IQ increasing in the US while declining in Northern Europe?

So why is this happening in Scandinavia but not in the US? Doesn't the US have just as many play stations and smartphones?

Django is not going to be rewritten in Julia. Neither is Linux going to be rewritten in Python. Different languages have different domains. Some of these comments seem to think all languages is competing in the same domain as if Rust is a direct competitor to Julia or JavaScript.

Rust will not steal Pythons dinner, they are used for completely different domains. The comment was saying that Rust might be a realistic alternative to C/C++/Fortran for modules which are not written in Python.

Good point about the learning curve. I don't think Rust is especially difficult overall, but you need to understand a lot before you get anywhere. Haskell kind of have the same problem, where you need to understand advanced features like monads before you can even write hello world.