[OT] Unity's HPC#

[Ola Fosheim Grøstad]

On Sunday, 19 May 2019 at 01:45:07 UTC, Margo wrote:
> And that is the issue, is it not. A small group of people are 
> not a reflection of a performance based HTTP solution.

Well, but I don't think a very high performance HTTP solution is 
a requirement to succeed for a language.

It is becoming a requirement to have an easy-to-use HTTPS 
solution. Easy to use with "normal" performance is far more 
important than being superior on some very narrow metrics. The 
vast majority of HTTP servers do not need very high theoretical 
HTTP performance.

If you really need high performance you would nevertheless have 
to look at a scalable distributed solution, and then you are 
locked to more tricky cloud based solutions that have been 
through heavy duty testing... which no small language can ever 
provide. You cannot establish market confidence of a high level 
of reliability without a large user base and backing by a major 
entity anyway. If you need to run something that requires a lot 
of throughput, then you probably also care a lot about 
established reliability and support.


> C++ has taken over most of D its advantages right? Rust is a 
> better C++ replacement.

I don't really think Rust is displacing C++. Rust has some of the 
same issues as D in that regard. Vendors support C++, not Rust. 
The biggest lost opportunity for D was to not align its lower 
level semantics with C++. If you choose to be different in ways 
that make you incompatible with the status quo then there should 
be substantial benefits to those choices.

For some Rust has provided that by their ownership model, but I 
suspect that it is not really used all that much for low level 
programming as it quickly becomes inconvenient. Rust seems to be 
much more of an application-engine programming language, it has a 
narrow application field where it is better than C++, but not if 
you look more broadly at all the areas where C++ is used.

> Maybe because despite being pre-1.0, it actually performance 5 
> times better then D? Its easy to judge a language on a label 
> without trying it out yourself, is it not :)

Both Crystal and D have LLVM based compilation, so for comparable 
codebases there should be no real difference.

Anyway, Crystal looks more like it would appeal to people looking 
for a replacement for a scripting language. Which is good. But it 
will never stand a chance in embedded programming. D could, if 
that had been a priority, sadly it isn't, so neither does D. As 
such C++ is pretty much irreplaceable at this point, unless you 
are willing to go out of your way to use something esoteric. Only 
a small minority do that.


> future. And as i pointed out in my post, there are simply 
> better alternatives for anything HTTP related then D. If you 
> can not handle this, ...

Better depends on what you try to achieve. To me being better for 
anything HTTP related has less to do with the language and more 
to do with the infrastructure around it as well as cloud support.

Also, it depends on what you interface with. Node.js might not be 
the best base for a HTTP server, but the fact that you get to use 
the same language on both server and client does make it superior 
for many developers.

Same goes for vibe.d.  If your write clients in D or has D as 
your main language then vibe.d will be superior in many cases.

Most HTTP sever-frameworks are simple and very similar. (Cloud 
solutions are more diverse.)