Comments by "Vitaly L" (@vitalyl1327) on "Rust Absolutely Positively Sucks" video.
-
24
-
14
-
@xelspeth Both C and Java are eager, imperative, structural, both having statements and expressions, both having very primitive (and very similar) type systems. Nothing fundamentally different. Compare that to, say, a lazy functional language, or to a total language, or even the eager languages of the ML family, or meta-languages with AST macros, or Prolog. That'd be worlds apart. But C and Java are almost the same on this scale.
7
-
@YMAS11
Languages can be classified on many dimensions, and choice of dimensions that matter is somewhat arbitrary.
One dimension is level of abstraction, it's the most well known classification but most people still get it wrong. On this axis, languages go from low level to high level, where low level is their operational semantics being close to some perceived view of the real hardware (talking about the real hardware makes no sense due to its massive complexity, so it's some abstract mental model, some RISC-y machine code).
From this extreme languages go to higher levels, with operational semantics being more and more steps removed from small step semantics of the machine code.
C, Java, Python - they are all very close to the low level side of this axis, as they have very explicit control flow, mostly explicit memory handling, explicit order of execution, and all use the same structural programming for expressing this low level control flow.
The higher you go on the levels of abstraction ladder, the less obvious control flow is, and it can become entirely undefined for very high level languages. They can have no tools for explicit control flow whatsoever. SQL or Datalog can be common examples of such.
Some languages allow to cheat and place themselves anywhere arbitrarily on this abstraction level axis. It's the meta-languages, with proper macro metaprogramming capabilities that allow you to add constructs with any, arbitrarily complex semantics to the language, turn the host language into any other language you can imagine. Rust belongs to this group - as it provides procedural macros that can turn the simple low-level Rust into, say, a very high level, optimised SQL.
Now, there are many other dimensions for classification, type systems among the most common ones. All of the common low level languages either use a very simple ad hoc type propagation and very loosely defined subtyping, or have entirely dynamic typing.
More complex type systems - including Hindley-Milner typing of the ML family and Miranda-Haskell-etc., Sytem F typing, dependent typing of Agda, Coq and alike - they all don't fit well into the low level, explicit control flow, structural programming model of the common languages.
Another dimension, which I decline to consider important, is the typical way the language is implemented. Natively compiled, natively compiled but with a complex runtime and managed memory, JIT-compiled with some intermediate representation (such as CLR or JVM), bytecode-interpreted such as Python or Perl - all such details are immaterial and it was shown many times how easily languages can be implemented on top of any of these models regardless of the other qualities of the language - see QuakeC, PyPy, multiple Java AOT implementations, etc.
As for algotrading - well, it exists, it makes money, it pays really well... What else can I say? I'm also grateful to it for driving higher end FPGA prices down due to growing demand.
5
-
4
-
4
-
3
-
3
-
3
-
3
-
3
-
2
-
2
-
@RotatingBuffalo
Now, I said "F*", not "F#", but you did not notice. "F*" is miles away from the run of the mill Hindley-Millner that F# does and Rust tries to do.
And let me remind you that we're talking about Rust here. Fairly mainstream language, with an ML-inspired type system, procedural macros, region analysis and a lot of other features from the "ivory tower" languages that you believe for no good reason to be impractical.
C and Java have very, very similar use cases. I worked on a high-frequency trading system that was largely written in Java. Eating C cake, evidently. I also worked on pure C HFT systems, ones written in C++, ones with large parts implemented in HDLs. There was no real difference in what C and Java did in those scenarios. Just plain, predictable imperative languages with more or less low level control of the memory layout. Nothing fancy. Everything very much the same. Not to mention java running on microcontrollers or even NFC chips (already mentioned JavaCard). For all practical purposes, Java is not too far from C. Yes, GC can and will cause troubles, yes, you need to code in a certain way for real-time, but same applies to C, your malloc() and free() are also not allowed.
2
-
2
-
2
-
2
-
2
-
2
-
2
-
2
-
2
-
2
-
2
-
1
-
1
-
1
-
1
-
1
-
1
-
@ardnys35 lol, you're dim, aren't you? Do you understand what semantics is? Have you seen many languages outside of the typical code monkey selection?
And before you dare to bark that those languages are not practical, you're just ignorant and have no right to have opinions on topics above your cognitive capacity. Don't you dare to claim that, say, APL is not practical, when a lot of quant analysts in finance use its derivatives (like K) all the time. And whe you compare K to C amd C to Python or Java, you'll see that C, Python and Java are just one language with tiny immaterial differences, while K is worlds apart from them all.
This whole thread is infested with primitive ignorant code monkeys with hurt egos, who just got confronted with the fact they know absolutely nothing about the languages. So funny when code monkeys get defensive and protect their ignorance.
1
-
1
-
1
-
1
-
@5dollasubwayfootlong you're a funny java monkey. Funny and pathetic. I worked once on a single code baee (one very specialised and very expensive CAD) that contained code in Fortran, PL/I, C#, Perl, Tcl and half a dozen of own DSLs, all acccumulated for over 30 years. I work on code bases that contain a lot of K, C++ and System Verilog with a good amount of Haskell added. You know, monkey, the kind of jobs that pay really well, especially the HFT jobs. There is always a lot of languages involved. But you, patbetitc monkey, would not know, nobody would ever let you anywhere close to such code bases. All you can hope for is some boring low paid CRUD trash.
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1