3 ms·

I want a modern C. I love/hate C. I mostly love Go. It has warts, but the philosophy works _for my brain_. Python will gain usecases as a meta-language as the

by kortex 6y ago

I want a modern C. I love/hate C. I mostly love Go. It has warts, but the philosophy works _for my brain_. Python will gain usecases as a meta-language as the ability to automatically wrap lower abstraction libaries improves. I see Julia eating much of Python's lunch, then python abstracting its way over julia, just because it can.

eigenspace 6y ago
> Python will gain usecases as a meta-language as the ability to automatically wrap lower abstraction libaries improves. I see Julia eating much of Python's lunch, then python abstracting its way over julia, just because it can. A big problem for Python as a glue language is interproceedural optimizations. In many important high performance applications, you really need the compiler to be able to make optimizations that cross function barriers, often barriers between user-written and developer-written functions. e.g. in differential equation solving, you can have a very fast integrator, and your user can have a very fast integrand, but if you don't have a compiler that's able to see and reason about both simultaneously, you're in trouble. This is why slapping Numba on a differential equation and sticking it in scipy integrators isn't even close to julia DifferentialEquation solvers. This is a very hard problem to solve in an ecosystem where there's so many different siloed compilers used by different Python packages. You'll always end up paying a performance price of the context switch. In julia, most things are written in pure julia, so the same compiler is seeing the entire program top to bottom. It's very nice. Furthermore, Julia has much power powerful metaprogramming facilities than Python does. It'll eat Python's lunch on that front too.
- Certhas 6y ago
  I can second this. I once implemented my own sparse matrix multiplication because I needed it in numba. Further, the type of automatic differentiation that is possible now is game changing. On the other hand Julia is a terribly designed language in some respects. Compare python error messages to Julias. It has all the problems of c++ templates baked in from the start. And latency is a real issue for now. I am always shocked when I drop back to Python for one task or another how responsive it feels. I think the latter might see a technical solution some time, e.g. by running code in the interpreter and swapping in jotted functions as they become available. The former it seems might have to wait for Julia 2.0 to start addressing...
  - eigenspace 6y ago
    There's actually a lot of work going into making better error messages right now. In 1.6 we're getting better highlighting of them in the REPL to emphasize the parts of the stacktrace that we think are actually relevant to the problem, and there's some discussion about mechanisms to mark functions as 'internal' so that they don't appear in stacktraces unless toggled to do so.
    - Certhas 6y ago
      That's great to hear! I am sure there is a lot of room for improvement and that would go a long way! But it also seems to me that with the language as it is now, the compiler simply doesn't have enough information to provide good error messages. E.g. there is no way to express the idea that something needs to be iterable to the compiler. Or that you expect an argument to be a function of a certain type. I'd love to be wrong on this though. :)
- kortex 6y ago
  I totally get your point, but that's still below the level of abstraction I'm talking about. Basically it boils down to, python's main trick is metaprogramming. If your interprocess optimization is a bottleneck, then write a framework which lets you put those pieces together under the hood. > Furthermore, Julia has much power powerful metaprogramming facilities than Python does. Until someone writes a way to import julia code directly into python/autogenerate it from python. Anyone who says "well then you're not really writing python" is missing the whole point: writing python is all about exactly this sort of tip-of-the-abstraction-iceberg trickery. Sure, you can call python from Julia as well. So it boils down to "which is the better glue language?" This isn't a competitive thing, it's just literally what Python is meant to do. https://pyjulia.readthedocs.io/en/latest/usage.html https://pyjulia.readthedocs.io/en/latest/usage.html
socialdemocrat 6y ago
Problem is that as Python starts using Julia more and more due to its top notch performance many will eventually question why they even use Python as they will realize Julia is a better language anyway.
MrBuddyCasino 6y ago
> I want a modern C. As in, a minimalist language aesthetic or fast low-level non-gc? Golang only has the aesthetics, Zig has both.

by kortex 6y ago

eigenspace 6y ago

> Python will gain usecases as a meta-language as the ability to automatically wrap lower abstraction libaries improves. I see Julia eating much of Python's lunch, then python abstracting its way over julia, just because it can. A big problem for Python as a glue language is interproceedural optimizations. In many important high performance applications, you really need the compiler to be able to make optimizations that cross function barriers, often barriers between user-written and developer-written functions. e.g. in differential equation solving, you can have a very fast integrator, and your user can have a very fast integrand, but if you don't have a compiler that's able to see and reason about both simultaneously, you're in trouble. This is why slapping Numba on a differential equation and sticking it in scipy integrators isn't even close to julia DifferentialEquation solvers. This is a very hard problem to solve in an ecosystem where there's so many different siloed compilers used by different Python packages. You'll always end up paying a performance price of the context switch. In julia, most things are written in pure julia, so the same compiler is seeing the entire program top to bottom. It's very nice. Furthermore, Julia has much power powerful metaprogramming facilities than Python does. It'll eat Python's lunch on that front too.

Certhas 6y ago
I can second this. I once implemented my own sparse matrix multiplication because I needed it in numba. Further, the type of automatic differentiation that is possible now is game changing. On the other hand Julia is a terribly designed language in some respects. Compare python error messages to Julias. It has all the problems of c++ templates baked in from the start. And latency is a real issue for now. I am always shocked when I drop back to Python for one task or another how responsive it feels. I think the latter might see a technical solution some time, e.g. by running code in the interpreter and swapping in jotted functions as they become available. The former it seems might have to wait for Julia 2.0 to start addressing...
- eigenspace 6y ago
  There's actually a lot of work going into making better error messages right now. In 1.6 we're getting better highlighting of them in the REPL to emphasize the parts of the stacktrace that we think are actually relevant to the problem, and there's some discussion about mechanisms to mark functions as 'internal' so that they don't appear in stacktraces unless toggled to do so.
  - Certhas 6y ago
    That's great to hear! I am sure there is a lot of room for improvement and that would go a long way! But it also seems to me that with the language as it is now, the compiler simply doesn't have enough information to provide good error messages. E.g. there is no way to express the idea that something needs to be iterable to the compiler. Or that you expect an argument to be a function of a certain type. I'd love to be wrong on this though. :)
kortex 6y ago
I totally get your point, but that's still below the level of abstraction I'm talking about. Basically it boils down to, python's main trick is metaprogramming. If your interprocess optimization is a bottleneck, then write a framework which lets you put those pieces together under the hood. > Furthermore, Julia has much power powerful metaprogramming facilities than Python does. Until someone writes a way to import julia code directly into python/autogenerate it from python. Anyone who says "well then you're not really writing python" is missing the whole point: writing python is all about exactly this sort of tip-of-the-abstraction-iceberg trickery. Sure, you can call python from Julia as well. So it boils down to "which is the better glue language?" This isn't a competitive thing, it's just literally what Python is meant to do. https://pyjulia.readthedocs.io/en/latest/usage.html https://pyjulia.readthedocs.io/en/latest/usage.html

socialdemocrat 6y ago

Problem is that as Python starts using Julia more and more due to its top notch performance many will eventually question why they even use Python as they will realize Julia is a better language anyway.

MrBuddyCasino 6y ago

> I want a modern C. As in, a minimalist language aesthetic or fast low-level non-gc? Golang only has the aesthetics, Zig has both.