6 ms·

This is only true because other people wrote the hot parts in other languages and exposed a python library. That’s fine but isn’t really fair in a battle of la

This is only true because other people wrote the hot parts in other languages and exposed a python library. That’s fine but isn’t really fair in a battle of languages

klyrs 6y ago
Good c interoperability is a benefit that Julia and Python share, and exploit for performance gains. They're on even footing here. Rust does it too, calling external unsafe code so they don't need to rewrite the world all in one go. I'd say that the extendability of a language isn't just fair, but a crucial aspect in comparing languages because that's what people do in the real world.
- adamnemecek 6y ago
  No, interop is so much simpler in julia. Not to mention cpp interop.
  - klyrs 6y ago
    Yeah, won't argue there; I was responding to the notion that python is somehow cheating by using numpy. Python has at least 3 paths to cpp interoperability now, but they've all got their warts.
    - adamnemecek 6y ago
      And they are require you to write wrappers. Peep the julia interop https://github.com/JuliaInterop/Cxx.jl https://github.com/JuliaInterop/Cxx.jl you just import your cpp code and it works.
      - newswasboring 6y ago
        This has been broken since v1.4 at least. You might want to peep CxxWrap
UMetaGOMS 6y ago
They did that because Python has an appealing user experience for people using that kind of code day-to-day. IMO this is what Julia missed; I've tried it at least once per year since first hearing about it in 2014 and the UX was horrible every time. Pretty sure if I ever found myself needing to write low-level numerical code I'd just use Fortran like everyone else. It's a real shame because Julia initially felt like it might develop to be the natural successor to Python in scientific computing, but over time that has seemed less and less likely.
- adamnemecek 6y ago
  When was the last time you tried and what problems did you encounter?
  - UMetaGOMS 6y ago
    Last year sometime - I'm about due another look. Main problems were cryptic errors in the REPL, super slow start-up and first run times (JIT issue I seem to recall reading was being improved), and a generally very poor third-party package management system. On the last issue, I'd say Python is not perfect but pip and various virtualenv management systems are "good enough". Having something like the Rust/Cargo setup is what I would prefer.
    - adamnemecek 6y ago
      It has gotten a lot better I think.
swsieber 6y ago
I think it's fair. We're not talking about that intrinsic language qualities, we're talking about what you can do. Or that's my take anyway. That's what I think of comparing when the lead line for the whole conversation is "tool belt".
- adamnemecek 6y ago
  The two are related. If i can't write fast code in the langauge itself but have to resort to another langauge, then that's very much a "what can you do with it" problem.
  - swsieber 6y ago
    And I'm saying doing stuff with numpy counts as doing stuff in python. Just because numpy is mostly implemented in c doesn't prevent me from writing ML in python.
    - adamnemecek 6y ago
      I understood. What if you need a feature that is not implemented in C and exposed? You need to write C.
      - michaelcampbell 6y ago
        Same issue with Julia, no?
        swsieber 6y ago
        Julia is much more amenable to implemening it though in native Julia, so I think it's a lot easier to stay out of C even when there's a similar library hole between Julia and Python. However, it's just a wall I haven't really bumped into. I suspect many people don't, and a part of that is popularity - so much exposure can do a lot to expose the warts. Though I think that goes for both Julia and Python. But I think once you know numpy well you probably won't run into that restriction (can extend in the native python) unless you're an expert (for the ML usecase).
collyw 6y ago
Looking at it that way, every language is just a wrapper around assembler.

This is only true because other people wrote the hot parts in other languages and exposed a python library. That’s fine but isn’t really fair in a battle of languages

klyrs 6y ago

Good c interoperability is a benefit that Julia and Python share, and exploit for performance gains. They're on even footing here. Rust does it too, calling external unsafe code so they don't need to rewrite the world all in one go. I'd say that the extendability of a language isn't just fair, but a crucial aspect in comparing languages because that's what people do in the real world.

adamnemecek 6y ago
No, interop is so much simpler in julia. Not to mention cpp interop.
- klyrs 6y ago
  Yeah, won't argue there; I was responding to the notion that python is somehow cheating by using numpy. Python has at least 3 paths to cpp interoperability now, but they've all got their warts.
  - adamnemecek 6y ago
    And they are require you to write wrappers. Peep the julia interop https://github.com/JuliaInterop/Cxx.jl https://github.com/JuliaInterop/Cxx.jl you just import your cpp code and it works.
    - newswasboring 6y ago
      This has been broken since v1.4 at least. You might want to peep CxxWrap

UMetaGOMS 6y ago

They did that because Python has an appealing user experience for people using that kind of code day-to-day. IMO this is what Julia missed; I've tried it at least once per year since first hearing about it in 2014 and the UX was horrible every time. Pretty sure if I ever found myself needing to write low-level numerical code I'd just use Fortran like everyone else. It's a real shame because Julia initially felt like it might develop to be the natural successor to Python in scientific computing, but over time that has seemed less and less likely.

adamnemecek 6y ago
When was the last time you tried and what problems did you encounter?
- UMetaGOMS 6y ago
  Last year sometime - I'm about due another look. Main problems were cryptic errors in the REPL, super slow start-up and first run times (JIT issue I seem to recall reading was being improved), and a generally very poor third-party package management system. On the last issue, I'd say Python is not perfect but pip and various virtualenv management systems are "good enough". Having something like the Rust/Cargo setup is what I would prefer.
  - adamnemecek 6y ago
    It has gotten a lot better I think.

swsieber 6y ago

I think it's fair. We're not talking about that intrinsic language qualities, we're talking about what you can do. Or that's my take anyway. That's what I think of comparing when the lead line for the whole conversation is "tool belt".

adamnemecek 6y ago
The two are related. If i can't write fast code in the langauge itself but have to resort to another langauge, then that's very much a "what can you do with it" problem.
- swsieber 6y ago
  And I'm saying doing stuff with numpy counts as doing stuff in python. Just because numpy is mostly implemented in c doesn't prevent me from writing ML in python.
  - adamnemecek 6y ago
    I understood. What if you need a feature that is not implemented in C and exposed? You need to write C.
    - michaelcampbell 6y ago
      Same issue with Julia, no?
      - swsieber 6y ago
        Julia is much more amenable to implemening it though in native Julia, so I think it's a lot easier to stay out of C even when there's a similar library hole between Julia and Python. However, it's just a wall I haven't really bumped into. I suspect many people don't, and a part of that is popularity - so much exposure can do a lot to expose the warts. Though I think that goes for both Julia and Python. But I think once you know numpy well you probably won't run into that restriction (can extend in the native python) unless you're an expert (for the ML usecase).

collyw 6y ago

Looking at it that way, every language is just a wrapper around assembler.