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? :)
KDB+ is Lisp under the hood. Please count as highly successful Lisp used in production.
> For typical desktop workloads memory bandwidth is not that important. Perhaps, I need to take that as an axiom, right? i7 5820K was non-typical for that matter then. And yes, Xeon-W with 5.3GHz frequency? Tell me more…
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…
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…
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…
You are not comparing apples to apples. Try finding any native code static typing compiler with RAD on board featuring quick compilation within 2x C++ resulting binary speed.
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,…
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.
Dyalog APL boasts a great IDE and really clever guys behind it. It is a real pleasure work with it.
Hm. I filled in email and duplicated it in description.
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? :)
KDB+ is Lisp under the hood. Please count as highly successful Lisp used in production.
> For typical desktop workloads memory bandwidth is not that important. Perhaps, I need to take that as an axiom, right? i7 5820K was non-typical for that matter then. And yes, Xeon-W with 5.3GHz frequency? Tell me more…
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…
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…
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…
You are not comparing apples to apples. Try finding any native code static typing compiler with RAD on board featuring quick compilation within 2x C++ resulting binary speed.
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,…
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.
Dyalog APL boasts a great IDE and really clever guys behind it. It is a real pleasure work with it.
Hm. I filled in email and duplicated it in description.