Personally, I expect implementing specifications properly. That's it.
About "commercial applications", let's face it. Those "enterprise solutions" cost way higher not because they are 10-1000x times "better", but because they contain generous "bonuses" for senior stuff.
Perhaps, it's the author does not want to name vendors which fail giving them time to contact him with some attractive suggestions. Or I am too suspicious? :)
Too bad they have only 2 channel memory controllers and same 32/32 L1 cache. That means all that power is still wasted waiting for memory (Max Memory Bandwidth 45.8 GB/s, seriously?).
Not sure why feeling so excited about those processors.
My main reason for using _proper_ dynamic languages (or better - dynamic languages VM - Lisps, APLs, etc.) is REPL/interactive debugger (stack restarts, walking the stack freely, changing/fixing functions while debugging).
The overall idea is keeping state across changes. That's of utmost importance for doing complex things.
And vice versa:
Restarting/recompiling to fix a small error while calculating something heavy? No, thanks.
BTW, Rust guys promised REPL by the end of 2018 :)
Well, yes.
The last comment says the issue is still there :)
I mean this bug alone in fact nullify the entire incremental compilation effort. It's kind of weird.
> The de-prioritization may lead to it getting fixed sooner, as Niko is a busy guy
Agree.
Moreover, Rust compiler contains some dark areas which nobody wants to deal with. See https://github.com/rust-lang/rust/issues/38528 for example. Basically it means that Rust compiler can suddenly take exponential time and space for compilation.
That bug really bites hard any code heavy on iterators (Rust often praised feature!). It has reliable reproduce test-case, but still it's already year old and was down-prioritized!
Hard to believe anybody uses Rust for real large project given so little attention to crucial details.
Broken multi-threading, broken string, ...
Care to elaborate? UTF8 move perhaps? Which native compiler/RAD got UTF8 for free? Virtually every C/C++ project was "broken" in that respect at some point or even now.
I use both Lazarus & FPC from trunk (in between releases) and even then backward compatibility is of top priority to FPC devs.
I highly doubt it's production code.
Nobody uses both objects(pointers) and interfaces simultaneously. It's a quick way to disaster.
In practice Delphi/FPC interfaces serve their purpose.
As a Delphi/FPC/Lazarus veteran (10+ years), comparing one of the quickest compilers with Qt/Boost C++ development cycle looks like a joke. Much faster edit-compile cycle which scales without issues up 1e6+ LOC (yes, modules/incremental compilation done right right from the start)
I guess you need to contact devs to clarify.
I regularly build from sources for Linux and cross-compile for Windows both x32 and x64 using just single "make ..." command.
>The problem is that Pascal have not any libraries (GUI, 2D/3D, Game Development Engines, programming micro-controllers, ...).
It's not true. Lazarus (http://www.lazarus.freepascal.org/) gives pretty much everything Delphi has.
Currently I develop OpenGL 2D analytical tool. Again GUI is on par with Delphi.
About "commercial applications", let's face it. Those "enterprise solutions" cost way higher not because they are 10-1000x times "better", but because they contain generous "bonuses" for senior stuff.