8 ms·
Please don't retrofit more stuff to make python work. move over to julia already. u can call python from Julia
by xiaodai 4y ago
Please don't retrofit more stuff to make python work. move over to julia already. u can call python from Julia
- deleted 4y ago[deleted]
- packetlost 4y agoI wouldn't consider Julia a replacement for Python
- Iwan-Zotow 4y agoand its an ugly thing they didn't get range composition right
- xiaodai 4y agocare to elaborate
- Iwan-Zotow 4y agoIn C and Python (which inherited it from C, I believe) for(int k = 0; k != N; ++k) { dowork(k); }, similar in Python ranges are [0...N). If I want just a sum, and would like to split work among multiple CPUs, I could write s = sum(0...N) or s = sum(0...N/2) + sum(N/2...N) or s = sum(0...N/3) + sum(N/3...5N/7) + sum(5N/7...N) and it will work beautifully. Ranges are decomposable and composable with any number(s) splitting original range. [0...N/2) + [N/2...N) = [0...N) When I first looked at Julia, I was ... unhappy. They didn't get simple ranges composability right. You could do it, sure, but it looks so ... unnnatural.
- packetlost 4y ago1 indexed arrays has me confused as hell
- Iwan-Zotow 4y agoyep, part of the problem
- nhgiang 4y agoNew language developers really overestimate most people's willingness to learn new languages
- cwp 4y agoYes. It's quite amazing really. Also, people really hate using more than one language. Web developers will twist themselves into incredible knots to avoid having to write HTML and CSS and Javascript in the same project.
- rpmisms 4y agoNonsense, we do it all the time, we just do it under the guise of Javascript. We just turned HTML into JSX and put our CSS in template literals.
- cwp 4y agoExactly.
- eyelidlessness 4y agoFor what it’s worth, while I’m perfectly comfortable with HTML and CSS, I prefer JSX + CSS-in-JS. This isn’t because it’s one language versus three. It’s because it promotes colocation of related code, and allows a high degree of composability that’s much harder to achieve otherwise. Colocation is great for understanding what a given thing does, and for identifying its dependencies. Composability is great for mapping a domain model to lower level concepts in a coherent way, and for encapsulating dependencies. This is somewhat achievable with separate languages. But it ultimately takes a very similar shape with additional tooling/ceremony and diminished benefits particularly from colocation.
- andrewflnr 4y agoNot that amazing. People who build languages are people who like languages, and therefore have tried a lot of them and find learning new ones easy and rewarding.
- 4y ago
- Archit3ch 4y agoAs someone in the Julia ecosystem, I wouldn't know where to begin with writing performant python. Is it Numba? Taichi? Torchscript? NumPy? Cython? Pypy? None of these seem to work together (besides calling each other, I suppose).
- montebicyclelo 4y agoWow, it seems like you have a number of good options to choose from. What a horrible situation, to have a language with a really rich ecosystem of powerful libraries.
- adgjlsfhk1 4y agoThe problem is you have 10 different options that all require rewriting your code and you can't share code with anyone who used any of the others (and almost all of them are still pretty slow compared to C++/Julia)
- jeron 4y agodecision paralysis is a real thing
- switchbak 4y ago10 options to make up for the deficiencies of the base language? I wouldn't call that a good thing.
- xiaodai 4y agoamen
- jakobnissen 4y agoIn my view they are a broad selection of bad choices, neither of whom will generally work to write fast code. I tried them all on my last large Python project (admittedly, 5 years ago since I switched to Julia since). Want to use NumPy? Better hope you have code that can be expressed as array computations (a tiny minority of performance sensitive tasks in my field of work). Cython? Now you're just writing another language, and get the joy of having to distribute compiled code in your Python package - for example, like the very fun segfaults I experienced because Conda will automatically override the system linker, breaking all compilation including my Cython modules. Numba? Hope you don't make custom classes - you know, one of the basic features of the language.
- montebicyclelo 4y agoI think the Julia people underestimate how many people, and how much those people, like the syntax of Python. If they'd stuck more to that they might have been able to have won more people over.. (white space, plus many other things).
- jarbus 4y agoAs someone who switched from python to Julia, Julia syntax supports things like list comprehensions, but also many better things like broadcasting that python really needs. The only thing python has over Julia is that Julia requires an “end” keyword where python uses indentation. But julia has so much more than python (like macros) that it’s just better syntax wise.
- BerislavLopac 4y agoPython has macros too.
- adgjlsfhk1 4y agoas of 2020 (PEP 638), python has macros (but they're still slightly janky). Before that there were decorators which look kind of similar but are a lot less powerful.
- nerpderp82 4y agoAre they implemented anywhere? It looks like the PEP is draft. You can do all the macro like things you want using framehacks and eval at the top level. Where they are hard to apply w/o direct support is down inside some function. Then you have to bytecode patch the result on first execution.
- mathisfun123 4y ago> as of 2020 (PEP 638) >> Reference Implementation >> None as yet. > but they're still slightly janky maybe you're from the future?
- 4y ago
- Buttons840 4y agoIt's been awhile, but last time I was doing serious work in Julia things were a little janky. For example, the REPL would segfault sometimes if I Ctrl-C'ed during heavy computations. And Flux at first seems like it will work on any code, which seems amazing, but then you find out at runtime that one of the operations you used isn't supported and get a runtime error. PyTorch might not work on regular Python code, but at least I know the APIs provided by PyTorch will work, even though they are a subset of what can be done in regular Python. Still, most things worked in Julia, and there have been many improvements since then so I suspect the few remaining rough spots are being smoothed out. In the future I will be happy if I get to work with Julia more.
- xiaodai 4y agoYeah. It's a chicken and egg thing. Imagine if resources applied to PyTorch was spent implementing in Julia. But then there's not enough users... so the cycle continues until one day Julia hits critical mass and a tipping point is reached.
- eastWestMath 4y agoI used to be very optimistic about Julia, but my enthusiasm has really cooled off the last year. I find JAX+jax_dataclasses gives me 90% of what I wanted from Julia (a nice monad library that is compatible with jit’ed code and the ability to cache compiled code would make it a solidly better language).
- staunton 4y agoI don't know whether the monad library is nice but caching compiles code is something they are making great progress on. Veraion 1.9 seems able to store most compiled code on disk.
- v3ss0n 4y agoIt was even close to death
- anst 4y ago
- alphanullmeric 4y agoAh yes, the language that claims to look like Python and run like C while not being particularly close in either aspect.
- smohare 4y ago[dead]
- catchnear4321 4y agoThe problem is I have no interest in calling Python from Julia, since I can just use Python.
- jalino23 4y agojulia is so nice but WHY did they have to decide to do a 1 based index?? like theres literally no reasonnnnnnnnnnnnnnnn
- xiaodai 4y agolet's see, fortran, r, matlab. all serious numerical languages have that. it's more natural 0 base indexing is only good for calculating memory offsets. Nothing else. like in go `vec[a,b]` is indexing `a` to `b-1` which is purely because it's more convenient due to 0-indexing. this `b-1` is hugely confusing and big gotcha for the layman.
- acmj 4y ago> all serious numerical languages have that. it's more natural And almost all serious general-purpose languages use 0-based. It is more natural at least to me. You see, this is exactly why 1-based index of Julia is disliked by many.
- xiaodai 4y agotaichi and julia aren't exactly aimed at general-purposes folks like u though. so there's that. you may not like rachel macadams, but she was never gonna be urs anyway. so meh
- wpietri 4y agoIf your goal is to promote Julia, your comments here are having exactly the opposite effect on me. Style aside, you can't simultaneously complain that Julia doesn't get the resources of a general-audience language and then talk down to "general-purposes folks". Julia could be the bees knees for math-y stuff. And if so, good for it. But Python's success is because its flexibility makes it pretty good for a wide range of things, even if it'll never be great for any one of them.
- xiaodai 4y ago
- l_theanine 4y ago[flagged]
- xiaodai 4y ago> Julia doesn’t have proper traits nor interfaces as opposed to Python? where type hints are just that. Hints. It's not even enforced. But u can use mypy... right.... yeah, retrofit more stuff on python. why not? (sarcastic). I am not a Chinese national btw, I am from Malaysia.
- l_theanine 4y agoI’m talking about code organization, not types. In Julia, methods are grouped together by type dispatch, mostly. There are times when code reuse comes into play where it’s helpful, but mostly it just confuses the issue and introduces ambiguity into the structure of the program in the big picture sense. My mistake, I saw your name was xiaodai and assumed. My point is, Julia is not suited for general software, and it’s questionable as a tool for technical computing as well. For running simulations and models where the code can be written and never looked at again, maybe it’s okay to use. But for anything else, Python is a lot nicer, and a lot more practical to write proper software in.
- nativecoinc 4y ago> My mistake, I saw your name was xiaodai and assumed. Oh my bad, I disregarded your comment based on your assumed Chinese nationality and “spam” (also assumed?). Since you’re not Chinese you’re worth my time. I don’t get it.
- l_theanine 4y agoLuckily, I wasn’t replying to you? Weirdo.
- cbkeller 4y agoI've seen this criticism that it's "difficult to reason about which method will actually be called because of the type system" once before, but it absolutely flummoxes me... I have literally never been confused about which method is going to be called by my code, and I'm not even a proper computer scientist (just a regular scientist scientist). Maybe this is just an issue of not having years of OO habits influencing the way I reason about dispatch in Julia?? Honestly not sure.
- ActorNightly 4y agoI used to hate Python too, but i complety 180ed in the past few years as I learned more about computer science. If you look at compute in general, it can be pretty much be summed up as add/multiply/load/store/compare/jump (straight from Jim Keller). All the other instructions are more specialized versions of that, with some having dedicated hardware in CPUS. If you need to do those 6 things as fast as possible, on single piece of hardware, you are most likely writing a video game. Thus video game development is pretty much C/C++ with a few things of Swift/C# sprinkled about. If a single piece of hardware requirement goes away (i.e you are writing a distributed system to serve a web app), people quickly figured out that hardware is cheaper than developer salary, and also network latency is going to be the dominant thing for speed. This is the reason Python took off - its super quick to write and deploy applications, and instead of paying a developer $10k+ a month, you can just spend half that on more EC2s that handle the load just fine, even if the end user has to wait 1.5 seconds instead of 1.1 for a result. If you don't need compare/jump, your program is essentially better off suited to running on the GPUs. OpenCL/CUDA came about because people realized that a lot of applications simply need to do math without any decisions along the way, and GPUS are much better at this. The paradigm is that you write kernels that you then load onto the GPU - this can be done in any language since you really just need to run the code once. I.e Python, despite being slow is used primarily for ML because of this. Then there is multiply/add only, which you probably best know in implementation as ASICs for bitcoin mining that blew GPUs out of the water. When you don't have memory controllers and just load/store from predefined locations, your speed goes through the roof. This is the future of ML chips as well, where your compiler looks a lot like the verilog/hdl compilers for FPGAs. Furthermore, with ML, the compare/jump and even load/store is being rolled into multiply/add. You have seemingly complex algorithms like GPT that make decisions, but without any branching. Technically speaking, a NAND gate is all you need to make a general purpose CPU and you need 2 neurons to simulate a NAND gate. So you can build an entire general purpose CPU from multiply/add. So in the end, its absolutely worth investing in Python and making it better. Languages like Julia are currently better suited to performant tasks, but the necessity of writing performant code to run on CPUs is going away slowly with every day. Its better to have a high purpose language that allows you to put ideas into code as quickly as possible, and then have different specializations for more generic tasks.
- deleted 4y ago
- okaleniuk 4y agoTried that. It was fun. Didn't see any benefit though, went back to Python. I don't care much about how the interface over LLVM looks like. As soon as I have the same result in the end, I'd rather stick to whatever has more users.
- v3ss0n 4y agoThat's quite silly. Julia ecosystem is non-existent. If we move nimlang would be the closest . PyPy shaping up nice for cext part and when fully compatible we will just use PyPy.org. Julia language features are really weak.