I don't think the std::chrono example is fair at all.

In the C++ case, you specify which clock you want. What kind of clock is DateTime.UtcNow()? Is it monotonic? What's the resolution? It's maybe in the documentation, but if the author refuses to remember simple syntax, surely he won't want to remember such details either.

The author also chose an example where he abuses the default behavior in the C# case. The last line in the C++ example just vanishes if you use the default behavior in both cases.

Also std chrono is very strict with types: time points and durations can't be freely mixed, milliseconds and microseconds have different types [1] and you can't implicitly convert from a float based time to an integer based time.

Does C# do the same thing?

[1] the underlying type actually encodes the exponent as a non-type template parameter. Converting from ms to us correctly applies the multiplicative factor.

> Does C# do the same thing?

To some extent. Points in time (DateTime) and durations (TimeSpan) cannot be mixed either, although you can subtract two DateTimes and get a TimeSpan, or add a TimeSpan to a DateTime. But I guess those work in C++ just as well.

Internally they are all based on ticks, which are 100-ns intervals (in DateTime since 0001-01-01) stored as a signed 64-bit integer. Different quantities of time don't need different types because there's only one type that represents a duration.

But with any complex interface, wouldn't it be a good idea to introduce a less complex facade that only deals with common usecases, and for complex use cases use that underlying interface?

The whole point of the complexity chrono interface is to prevent mistakes caused by accidentally mixing different units. Providing a default unsafe interface would completely defeat the point.

That an interesting point of view to take in defence of C++ of all things.

Sorry, I might misparsing your replay, but are you saying that std::chrono is overly strict? Or that because C++ (and its C heritage) has allowed unsafe implicit conversions in the past, it should continue doing it in the future?

Just that it feels strange to see safe defaults/interfaces used to argue for C++, nothing more.

"I can learn Go or code stuff in Python (or even Java/C#) which 99% of the cases is fast enough I used to advocate for complex stuff, but now I think differently. Solve my problem, I don't care about religious issues."

This sounds like it's written in the hobbyist/lone tinkerer/ deploying to self managed server context.

When discussing could anything replace C++ one is usually in the context of a massive business environment pending on millions of lines of C++ and native bindings, not figuring out how to write a handy personal tool.

For handy personal tools, Python is probably much better than C++ 99% of time, but when discussing, how to replace a language in an entrenched ecological slot with a huge number of interdependencies things are really not that simple at all.

> Python and Go

> 99% of the cases is fast enough

This claim is unsubstantiated hyperbole.

how dare they.

Right, bro? That's what I'm saying. Misinformation is no bueno