Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Strong arrows: a new approach to gradual typing

elixir-lang.org

Post reply on HN
Print view View original

61–70 of 87 posts

Re: Strong arrows: a new approach to gradual typing

#61

Post by [deleted] »

jovial_cavalier wrote: post #43
adgjlsfhk1 wrote: post #35

Earlier quoted context omitted.

This is not true 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.

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."

[deleted]

Re: Strong arrows: a new approach to gradual typing

#62

Post by jovial_cavalier »

tjrgergw wrote: post #60
jovial_cavalier wrote: post #59

Earlier quoted context omitted.

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.

Sure, if you're solving easy problems python will be fine.

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.

Re: Strong arrows: a new approach to gradual typing

#63

Post by tjrgergw »

jovial_cavalier wrote: post #62
tjrgergw wrote: post #60

Earlier quoted context omitted.

Sure, if you're solving easy problems python will be fine.

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…

LOL no, it's not a little faster than python :D

I just showed you that it's possible to generate native code ahead of time but you ignored that. Now you've moved on to the "next" objection. Anyway, good luck with your life.

Re: Strong arrows: a new approach to gradual typing

#64

Post by adgjlsfhk1 »

jovial_cavalier wrote: post #43
adgjlsfhk1 wrote: post #35

Earlier quoted context omitted.

This is not true 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.

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."

with the first example on https://www.json.org/example.html and the following Julia code

using JSON3

data = JSON3.read("test.json")

println(data[:glossary][:title])

running `time julia +release --project=. --startup-file=no test.jl` gives a total time spend of 0.39 seconds (running on a dev version of Julia brings it down to 0.30). The translation of this into python is faster (.02 seconds), but this means that as long as your script has at least a second or so of work to do, Julia will be faster.

Specifically, the timing breakdown is 0.07 seconds to launch julia, 0.07 seconds to load JSON3, 0.0001 seconds to parse the file, .07 seconds of compilation for the indexing (I'm pretty sure this is fixable on the package side, see https://github.com/quinnj/JSON3.jl/pull/271), and 0.0001 seconds to do the indexing

Re: Strong arrows: a new approach to gradual typing

#65

Post by adgjlsfhk1 »

jovial_cavalier wrote: post #62
tjrgergw wrote: post #60

Earlier quoted context omitted.

Sure, if you're solving easy problems python will be fine.

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…

It's worth noting that the benchmarkgame is including startup time. If you look at the execution time (which is what matters once you start doing more work) the speeds are equal. For example, https://arxiv.org/pdf/2207.12762.pdf shows Julia beating hand codes BLAS kernels for the 2nd fastest supercomputer in the world.

Re: Strong arrows: a new approach to gradual typing

#66

Post by tjrgergw »

adgjlsfhk1 wrote: post #65
jovial_cavalier wrote: post #62

Earlier quoted context omitted.

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…

It's worth noting that the benchmarkgame is including startup time. If you look at the execution time (which is what matters once you start doing more work) the speeds are equal. For example, https://arxiv.org/pdf/2207.12762.pdf shows Julia beating hand codes BLAS kernels for the 2nd fastest supercomputer in the world.

Leave him alone. He already made up his mind, you're just confusing him with facts.

Re: Strong arrows: a new approach to gradual typing

#67

Post by josevalim »

charcircuit wrote: post #56
hughw wrote: post #9

Earlier quoted context omitted.

I guess I'd be glad to have my type system designed by people well grounded in theory.

Not if it results in the type system being optimized for type theorists to play around with and not to assist developers in making real projects.

This is a surprising assessment given most of the blog post is explaining how to build the type system in a way it can give feedback on all _existing real projects_ already written in Elixir. :)

It is the opposite of optimizing for type theorists and rather exploring how to bring values to the existing millions of lines of code.

Edit: I am the author.

Re: Strong arrows: a new approach to gradual typing

#68

Post by sodapopcan »

anonyfox wrote: post #31
di4na wrote: post #19

Earlier quoted context omitted.

Tbf. While more money to allows stability of people involved would help, it would not really speed it up that much. Typescript had ms behind it and it still took a decade. At some point the engineering, experiments and learning take time and you can hardly speed it up with more ressources.

Maybe more like different layers could do different strategies? I can't even imagine what could happen to the BEAM itself if there are the same amount of ressources put on it like in our modern JS engines that have come a loooong way. Its already an amazing piece of tech in itself, but I wonder what an army of experts could do ontop of it.

Then we might have NPM for the BEAM--Uber popularity isn't always a good thing. Don't get me wrong, though, I want Elixir to get more popular.

Re: Strong arrows: a new approach to gradual typing

#69

Post by _a_a_a_ »

alphablended wrote: post #49
tjrgergw wrote: post #18

"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 perfo…

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 la…

> 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.

Re: Strong arrows: a new approach to gradual typing

#70

Post by jovial_cavalier »

adgjlsfhk1 wrote: post #65
jovial_cavalier wrote: post #62

Earlier quoted context omitted.

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…

It's worth noting that the benchmarkgame is including startup time. If you look at the execution time (which is what matters once you start doing more work) the speeds are equal. For example, https://arxiv.org/pdf/2207.12762.pdf shows Julia beating hand codes BLAS kernels for the 2nd fastest supercomputer in the world.

I agree that if you keep increasing n on any of these benchmarks, Julia and C should start to approach each other, but the JIT overhead is not meaningless. I think there’s a reason benchmarkgame includes it.

It sounds, though, like they’ve started to seriously address this in versions more recent than what I’ve played with. I suppose I’ll check it out again.

Post reply on HN