4 ms·

"gradual typing" is exactly how I code Julia. Disclaimer: this is not how to the strengths of Julia are normally described by most people, it's just how I thin

"gradual typing" is exactly how I code Julia. Disclaimer: this is not how to the strengths of Julia are normally described by most people, it's just how I think about it. You might have heard that Julia solves the two language problem (easy as python, fast as C++). But exactly how does it do that? In python you don't have to care about types, but even if you were willing to care about types you wouldn't get any performance benefit. In C++ you have to care about types, you don't have the option not to, even when you don't care about performance. In Julia you don't have to care about types. You can code it exactly as python. But if you are willing to you can care about types, and you'll get a huge performance benefit. So, the way I code Julia is on a first pass I code it like python. I don't care about types, I just care that it's correct. Then, after it's correct, and if performance is critical, I start thinking about types. So Julia very much lends itself to "make it work, make it right, make it fast", by allowing you to gradually introducing types into the parts of your code that matter.

jovial_cavalier 3y ago
Julia is slower than Python for most applications if you include the compile time (which is every time you run your program, because it's "just in time"). edit: I want to be clear - I like Julia, and I have long wanted a scripting language that was gramatically simple like python but had support for strong typing, etc. But the TTFX problem, for me, muddies the waters on the question of "which is faster, Julia or Python?"
- tjrgergw 3y ago
  You compile your code every time you run it? Yikes. Sorry to hear that.
  - jovial_cavalier 3y ago
    Is there a way to get around that in Julia? I tried to find a way to compile programs directly, and was disappointed with what was on offer.
    - tjrgergw 3y ago
      https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl https://julialang.github.io/PrecompileTools.jl https://julialang.github.io/PrecompileTools.jl https://julialang.org/blog/2023/04/julia-1.9-highlights/#caching_of_native_code https://julialang.org/blog/2023/04/julia-1.9-highlights/#cac...
- johnbcoughlin 3y ago
  What does "most applications" mean?
  - jovial_cavalier 3y ago
    Most code that is written is code that is run frequently and with a short runtime. Julia is not good at this.
- eigenspace 3y ago
  Maybe if your program is just println("hello world!") Julia also has done a lot lately[1] to cache the results of JIT compilation from packages and re-use it later. So if you're doing a lot of println("hello world!") or whatever, you can make that faster by bundling it in a package and adding a precompile workflow. This will also be improving more with upcoming releases. [1] https://julialang.org/blog/2023/04/julia-1.9-highlights/#caching_of_native_code https://julialang.org/blog/2023/04/julia-1.9-highlights/#cac...
- adgjlsfhk1 3y ago
  This is not true https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... shows the middle of the pack julia implementations being over 10x faster than the fastest python implementations including startup and compile time.
  - jovial_cavalier 3y ago
    On contrived benchmarks, sure. What if I want to, say, parse a json file and print something from it? I understand that Julia is scientific computing oriented, and is probably faster than Python for those applications, but the fact is that Python is no slouch when it comes to scientific computing. And it can do a lot more, including simple but powerful scripts, which is what I mean when I say "most applications."
    - tjrgergw 3y ago
      > contrived benchmarks Why is doing actual science more of a contrived benchmark than parsing and printing a json? I think this says more about what you personally do than anything else.
      - jovial_cavalier 3y ago
        Most code is that. N-body problems and computing the julia set are cool and beautiful and important. But most code is plumbing scripts that get run for .5s 10,000,000 times a day.
        tjrgergw 3y ago
        Sure, if you're solving easy problems python will be fine.
        jovial_cavalier 3y ago
        And if you're solving hard problems, it's fine too. That's my only point. You'll see on that same benchmark page that C is 2-3x faster than Julia. If you want performance, use C. Julia is this weird middle ground where it has the simplified syntax of Python, is a little faster than Python, but still slower than C. Anything that needs to be done in real time will be optimized into a "real" language like C, C++ or Rust.
alphablended 3y ago
The way you use the word "correct" is interesting: in PL theory circles, it usually means : "bug free", but it appears that you use it to mean: "produces the results I'm looking for". Indeed, one may write a program which is bug free, yet does not implement the algorithm that produces the expected result (for instance, a program sorting data in ascending order, when a descending order is needed). In strongly typed languages, type systems are used to ensure that programs are bug free, following the adage : "if it compiles, it works". The issue of having a proper implementation is not a concern of researchers in their papers, it's purely an engineering problem, so there is no interest for them in using the word correct in that sense. Also, with type inference, one often does not have to mind too much about types, and instead gradually introduce type annotations to lift disagreements between the compiler and its user. Gradual typing is yet another tool to achieve a similar result.
- _a_a_a_ 3y ago
  > In strongly typed languages, type systems are used to ensure that programs are bug free, following the adage : "if it compiles, it works". (chokes on his latte) - could you elaborate on this, cos, much as I love strong typing, it surely don't mean 'bug free' at the end, not in any way useful sense.
  - urxvtcd 3y ago
    This is a slightly above my pay grade, so take it with a bit salt. Type systems in general reject some programs as invalid, but this claim is usually made with powerful type systems in mind; think Haskell, Idris, Rust. I only played with these casually, but it is true that you can write some code, and then let yourself be guided by compiler in fixing all the errors. It's often the case that the resulting program just works. Rust's borrow checker is a part of its type system, based on some flavor of linear types if I remember correctly. Think about it: the type system can protect you from double frees. This is powerful. In Haskell, for starters, you can't do any side effects outside of IO monad. You can express precisely what a given function is allowed to do. In dependently-typed languages you can express that, for example, a function concatenating lists of length n and m returns a list of length n + m. And aside from these above there is a lot of other, less magical things: no nulls, exhaustiveness checks for ADTs, some focus on immutability, lack of exceptions, and so on. Now, I doubt we are all going to write Idris in five years, and even there bugs do happen obviously. But the idea compiles==works is not entirely out of this world.

jovial_cavalier 3y ago

Julia is slower than Python for most applications if you include the compile time (which is every time you run your program, because it's "just in time"). edit: I want to be clear - I like Julia, and I have long wanted a scripting language that was gramatically simple like python but had support for strong typing, etc. But the TTFX problem, for me, muddies the waters on the question of "which is faster, Julia or Python?"

tjrgergw 3y ago
You compile your code every time you run it? Yikes. Sorry to hear that.
- jovial_cavalier 3y ago
  Is there a way to get around that in Julia? I tried to find a way to compile programs directly, and was disappointed with what was on offer.
  - tjrgergw 3y ago
    https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl https://julialang.github.io/PrecompileTools.jl https://julialang.github.io/PrecompileTools.jl https://julialang.org/blog/2023/04/julia-1.9-highlights/#caching_of_native_code https://julialang.org/blog/2023/04/julia-1.9-highlights/#cac...
johnbcoughlin 3y ago
What does "most applications" mean?
- jovial_cavalier 3y ago
  Most code that is written is code that is run frequently and with a short runtime. Julia is not good at this.
eigenspace 3y ago
Maybe if your program is just println("hello world!") Julia also has done a lot lately[1] to cache the results of JIT compilation from packages and re-use it later. So if you're doing a lot of println("hello world!") or whatever, you can make that faster by bundling it in a package and adding a precompile workflow. This will also be improving more with upcoming releases. [1] https://julialang.org/blog/2023/04/julia-1.9-highlights/#caching_of_native_code https://julialang.org/blog/2023/04/julia-1.9-highlights/#cac...
adgjlsfhk1 3y ago
This is not true https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-python3.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... shows the middle of the pack julia implementations being over 10x faster than the fastest python implementations including startup and compile time.
- jovial_cavalier 3y ago
  On contrived benchmarks, sure. What if I want to, say, parse a json file and print something from it? I understand that Julia is scientific computing oriented, and is probably faster than Python for those applications, but the fact is that Python is no slouch when it comes to scientific computing. And it can do a lot more, including simple but powerful scripts, which is what I mean when I say "most applications."
  - tjrgergw 3y ago
    > contrived benchmarks Why is doing actual science more of a contrived benchmark than parsing and printing a json? I think this says more about what you personally do than anything else.
    - jovial_cavalier 3y ago
      Most code is that. N-body problems and computing the julia set are cool and beautiful and important. But most code is plumbing scripts that get run for .5s 10,000,000 times a day.
      - tjrgergw 3y ago
        Sure, if you're solving easy problems python will be fine.
        jovial_cavalier 3y ago
        And if you're solving hard problems, it's fine too. That's my only point. You'll see on that same benchmark page that C is 2-3x faster than Julia. If you want performance, use C. Julia is this weird middle ground where it has the simplified syntax of Python, is a little faster than Python, but still slower than C. Anything that needs to be done in real time will be optimized into a "real" language like C, C++ or Rust.

alphablended 3y ago

The way you use the word "correct" is interesting: in PL theory circles, it usually means : "bug free", but it appears that you use it to mean: "produces the results I'm looking for". Indeed, one may write a program which is bug free, yet does not implement the algorithm that produces the expected result (for instance, a program sorting data in ascending order, when a descending order is needed). In strongly typed languages, type systems are used to ensure that programs are bug free, following the adage : "if it compiles, it works". The issue of having a proper implementation is not a concern of researchers in their papers, it's purely an engineering problem, so there is no interest for them in using the word correct in that sense. Also, with type inference, one often does not have to mind too much about types, and instead gradually introduce type annotations to lift disagreements between the compiler and its user. Gradual typing is yet another tool to achieve a similar result.

_a_a_a_ 3y ago
> In strongly typed languages, type systems are used to ensure that programs are bug free, following the adage : "if it compiles, it works". (chokes on his latte) - could you elaborate on this, cos, much as I love strong typing, it surely don't mean 'bug free' at the end, not in any way useful sense.
- urxvtcd 3y ago
  This is a slightly above my pay grade, so take it with a bit salt. Type systems in general reject some programs as invalid, but this claim is usually made with powerful type systems in mind; think Haskell, Idris, Rust. I only played with these casually, but it is true that you can write some code, and then let yourself be guided by compiler in fixing all the errors. It's often the case that the resulting program just works. Rust's borrow checker is a part of its type system, based on some flavor of linear types if I remember correctly. Think about it: the type system can protect you from double frees. This is powerful. In Haskell, for starters, you can't do any side effects outside of IO monad. You can express precisely what a given function is allowed to do. In dependently-typed languages you can express that, for example, a function concatenating lists of length n and m returns a list of length n + m. And aside from these above there is a lot of other, less magical things: no nulls, exhaustiveness checks for ADTs, some focus on immutability, lack of exceptions, and so on. Now, I doubt we are all going to write Idris in five years, and even there bugs do happen obviously. But the idea compiles==works is not entirely out of this world.