snicker7

Mentioned paper: https://arxiv.org/abs/2112.14714

Abstract:

This thesis proposes an advanced, generic and high-level code rewriting and analysis system in the Julia programming language, providing applied equality saturation in the presence of multiple dispatch and metaprogramming. We show how our system can practically solve some challenging problems: Can programmers implement their own high-level compiler optimizations for their domain-specific scientific programs, without the requirement of them being compiler experts at all? Can these optimizers be implemented by users in the same language and inside the same programs they want to optimize, solving the two-language problem? Can these compiler optimizers be written in a high-level fashion, as equations, without the need to worry about the rewriting ordering? Thus, can symbolic mathematics do high-level compiler optimizations or vice-versa?

Writing system software in Rust is an awful choice. Use Julia instead. /s

Time is a number. At least, it makes sense to subtract them (I guess you can say that time is a one dimensional affine space).

Doesn't 700 requests per second for such a trivial service seem kinda slow?

China is not a rich country per capita (on par with LATAM), but it’s massive size is what attracts businesses.

Even though this posts thesis is “trade offs”, it doesn’t really talk about any technical advantages that the Python’s AD ecosystem (Tensorflow, PyTorch, JAX) has over Julia’s (Zygote.jl, Diffractor.jl).

“Fix-it Fridays” are a great idea, and something that should be adopted beyond remote teams.

For software engineering, four hours of actual work per day is probably average even on-site.

Check out Guix via Nix package definitions. Nix looks far more hacky (embedded shell scripts are standard). Guix package defs are declarative and readable (even for those with little Lisp exposure).

Guix is not tied to any kernel version. Hurd and Linux-libre are officially supported. But it is trivial for users to incorporate non-free firmwares.

Check out some Guix package definitions. They are written in a declarative style. It looks closer to YAML than code.

It's a shame that JuliaDB was basically abandoned. I work in the financial industry, and I could see Julia competing with KDB+. Unfortunately, the Julia data engineering stack is far behind the data science stack.

DuckDB is an embedded database. That is, it is a library one loads into their application. This is in contrast to a server database like Postgres where the database and application live on different processes (usually on different machines).

DuckDB is often compared to SQLite. But a more apt comparison might be KDB+, a proprietary vector embedded database.

???

I am referring to a hypothetical dockerless OCI compatability layer built on top of `guix shell --container` or `guix system container`.

I sort of got this idea from runj [0], an attempt to create an OCI compatible runtime for FreeBSD jails.

The main advantage is to use certain OCI-compatible tools (e.g. k8s) with Guix without needing to use Docker.

[0] https://samuel.karp.dev/blog/2021/03/runj-a-new-oci-runtime-...

Guix supports exporting to Docker containers. A guix.scm file then becomes a reproducible alternative to a Dockerfile.

However, Guix has its own container implementation. And this is significantly lighter than Docker (instead of layers, links to /gnu/store) and is root-less. If Guix containers had a runc-compatability layer and better docs/tutorials, it would be hard to go back to Docker/podman.

My team is distributed across the world. We ensure that we have multiple SME’s for the most critical systems in each region. No one has to wake up at 3 AM.

At a certain income threshold, rent becomes irrelevant. The difference in top decile salaries between, say, NYC and Pittsburgh is far more significant than the slight difference in a rent.

I work at a hedge fund. Despite a recent return-to-work mandate, literally no one in my team is in the office. Our job is super stressful and emotionally taxing. Not having wearing to pants makes it somewhat bearable.

I think the issue with code vectorization is that the compiler must know that the given loop can run out-of-order. I don't know if that is something that LLVM can do reliably.

It comes down to timing, really. Just like most technology fads.

Python is interpreted/dynamic, open source, general-purpose, relatively popular, and is easy to write low-overhead wrappers to C/C++/Fortran libraries. In 2008-2010, when ML took off, Python was the only language with these properties.

Python, however, has its problems: an atrocious concurrency story (GIL, colored coroutines, asyncio vs trio rift, fork is inefficient thanks to GC, etc), highly non-compostable (especially in scientific computing), and package management is broken. The language is also inherently slow (unfixable). It will be replaced by something else eventually.

Except that institutional credibility is literally a made-up resource that tax payers like myself are subsidizing.

Does it do time tracking / habit tracking? Agendas? Org mode is more than just a todo app.

Keep in mind that AMDGPU.jl requires ROCm, which is basically dead (no recent GPUs support it and none of those that do are consumer-grade).

The problem with AMD GPGPU is not software, it is that AMD literally does not care.

People are being overly cynical. People are not born as senior engineers. You must start somewhere.

Putting more of your application logic in your database is great for DB vendors. Its pretty much impossible to migrate to a competitor.

Built on top of pandoc and used to build the Julia Data Science book: https://juliadatascience.io/

The Lisp and APL families of languages do not have operator precedence at all.

This sort of language cruft makes me realize that Lisp had it right all along.

Author argues that a wealth tax will encourage short-term over long-term growth. But a wealth tax is also a disincentive for public ownership. And some argue that short-term thinking prevails to satisfy the whims of the public market.

The main take away from this article is doing FFI between two language (Ruby wrapping Julia), taking into account the particularities of their divergent runtimes.