51–60 of 95 posts
Unclear if this has been in the works longer as the graalvm LLVM build of python discussed yesterday[1]. The first HN discussion is from 2022 [3]. Any relation? Any comparisons? Funny I can't find the license for graalvm python in their docs [2]. That could be a differentiator. - [1] GraalVM Python on HN https://news.ycombinator.com/item?id=41570708 - [2] GraalVM Python site https://www.graalvm.org/python/ - [3] HN D…
> Strings: Codon currently uses ASCII strings unlike Python's unicode strings.
That seems really odd to me. Who would use a framework nowadays that doesn't support unicode?
Instead of building their GPU support atop CUDA/NVIDIA [0], I’m wondering why they didn’t instead go with WebGPU [1] via something like wgpu [2]. Using wgpu, they could offer cross-platform compatibility across several graphics API’s, covering a wide range of hardware including NVIDIA GeForce and Quadro, AMD Radeon, Intel Iris and Arc, ARM Mali, and Apple’s integrated GPU’s. They note the following [0]: > The GPU mod…
WebGPU while stating compute is within their design I would imagine is focused on presentation/rendering and probably not on large demanding workloads.
Earlier quoted context omitted.
The license is the "Business Source License 1.1" [1]. The Business Source License (BSL) 1.1 is a software license created by MariaDB Corporation. It's designed as a middle ground between fully open-source licenses and traditional proprietary software licenses. It's kind of neat because it's a parameteric license, in that you can change some parameters while leaving the text of the license unchanged. For codon, the "C…
From what I've seen is the "Change Date" is usually updated so you always have a few years older software as Apache License and the latest software as BSL
What's up with their benchmarks[1], it just shows benchmark names and I don't see any numbers or graphs. Tried Safari and Chrome. [1]: https://exaloop.io/benchmarks/
It’s not surprising that you can make a static compiler that makes tiny little programs written in a dynamic language into fast executables.
The hard part is making that scale to >=10,000 LoC programs. I dunno which static reasoning approaches codon uses, but all the ones I’m familiar with fall apart when you try to scale to large code.
That’s why JS benchmarking focused on larger and larger programs over time. Even the small programs that JS JIT writers use tend to have a lot of subtle idioms that break static reasoning, to model what happens in larger programs.
If you want to get in the business of making dynamic languages fast then the best advice I can give you is don’t use any of the benchmarks that these folks cite for your perf tuning. If you really do have to start with small programs then something like Richards or deltablue are ok, but you’ll want to diversify to larger programs if you really want to keep it real.
(Source: I was a combatant in the JS perf wars for a decade as a webkitten.)
Earlier quoted context omitted.
parsing json is roughly of the type: type Json = None | bool | float | str | dict[str, Json] | list[Json] you might have similar situations for configs e.g. float | str for time in seconds or a human readable time string like "30s" etc. given how fundamental such things are I'm not sure if there will be any larger projects (especially wrt. web servers and similar) which are compatible with this also many commonly use…
Agreed, I was just joking. I understand heterogenous lists are possible with Python, but with the use of static type checking I feel like its pretty rare for me to have heterogenous lists unless its duck typing.
Whether that's a feature is hard to say. Your language stopped you thinking in those terms, and stopped your colleagues from doing so. Did it force clarity of thought or awkward contortions in the implementation? Tends to depend on the domain.
Earlier quoted context omitted.
return [key, value]
Why would you do this over `return key, value` which produces a tuple? Just curious.
Earlier quoted context omitted.
Well would you claim that Python 3.5 isn't python?
All versions of python are python. If lang is not compatible with any of python versions, then the lang isn’t python. False advertising is not nice. (even if the fineprint clarifies)
Python versions are not compatible between themselves, as python does not preserve backward compatibility, ergo python is not python.