5 ms·
Julia is designed to seem to win arguments as best I can tell... If you complain about the need to break abstractions and the lack of general purpose applicatio
by th0ma5 3y ago
Julia is designed to seem to win arguments as best I can tell... If you complain about the need to break abstractions and the lack of general purpose application you're accused of not understanding. When you say it slow they say you can inline assembler, and when you say that's dumb why have a high level language then, they then say well you don't have to it is fast as is and everyone else is slow, and it just devolves into circular arguments. Abstractions exist in layers for reasons.
- sainez 3y agoYou can obviously provide the same abstraction with different implementations that yield different performance characteristics. Julia provides the same level of flexibility (if not more) as Python without any of the design decisions which cause Python to be so slow. I fail to see how this is a contentious point.
- th0ma5 3y agoYeah this is a great example of what I'm saying. You obviously don't understand Python then.
- adgjlsfhk1 3y agowhen you say Julia is slow, what are you talking about? even without any fancy tricks, normal Julia code is usually the same speed as the equivalent normal C code
- th0ma5 3y agoYes this is another great example... If Julia is fast then why do you need to inline assembler ?
- adgjlsfhk1 3y agoFor the same reason that C/C++ allow inline assembly? Languages come in roughly 3 speeds. Slow (e.g. python/R), mostly not slow (e.g. Java/Go), and not slow (e.g. C/Rust). If you want actually fast code (e.g. the speed of BLAS/FFTW etc) you need the combination of a not slow language, code generation, and often hand-coded assembly for the most performance critical parts.
- th0ma5 3y agoI noticed you didn't mention Julia explicitly this time because when you outline the abstractions like this it seems silly to claim something about Julia magically solves the position and purpose of these layers. I can write a PySpark job based on a tutorial that would run circles around a single core Julia process that was designed with contradictory requirements. I just don't see how Julia gets away with claiming it solves all of this in the first page of their documentation without a ton of qualifiers... Except to say that is Julia that's what they do, they make bold claims that obfuscate what performance is and where it comes from.
- adgjlsfhk1 3y agoTo be explicit about where julia fits in here, Julia is a "not slow" language (you could make an argument for it being on the faster end of "mostly not slow" due to GC) that also has enough high level features (higher order functions, macros, memory management, general ease of use) to work as a high level language. You absolutely can write a distributed python codebase that runs faster than single core julia, but doing so will likely be harder than writing the distributed/threaded Julia code that is way faster than PySpark.
- th0ma5 3y agoYeah citation needed on that one, but it is a dumb hypothetical on my part to illustrate the problem. Another hypothetical, how do you get junior people to support your inline ASM? If it makes this easy to do, it makes the technical debt that much more rampant.
- adgjlsfhk1 3y agoYou seem really hung up on this inline asm thing. It's not like most julia code is just inline assembly. It's something that at a rough estimate, .5% of packages use to let you squeeze out the final drops of performance that then gets wrapped in an API that looks like normal julia code. This isn't any different from C/C++ which also in some low level code bases will have calls to compiler directives or inline assembly.