PSA: On the surface it looks great - but it's something that spawns a Python server (with uv - I think) and does communicate with it during tests. I don't think it's complexity we need to take on on our unit tests.
A saner approach would be to start with a FFI-friendly language and create bindings. I don't think just being able to use an already written framework in Python is worth the trade-off.
Trying to make my Rust library `composable-indexes` more ergonomic. It is for indexing a collection on multiple dimensions in a type-safe and composable manner.
In other words, something safer & more concise than maintaining multiple HashMap's, but a lot less involved & simpler than an in-memory SQLite.
You are right, the best region that optimises median latency against all internet users over the world is `us-west-3`, which is Paris - I believe. Likely because it has much better latency towards Asia where the majority of internet users are.
I also investigated which two regions to choose for a multi-region setup, which ends up being London and Japan.
Turkish here. It's hard to believe, but there are different kinds of ice cream in Turkey.
The average ice-cream ("dondurma" in Turkish) you'd get in Turkey is the one you expect: sorbet or gelato, usually in a cone. It's what you'd get when you ask for an ice-cream at a random place.
The one described in this post is a specific kind of ice-cream we call "ice-cream from Maraş" ("Maraş dondurması" in Turkish). Which is great - but the post makes it sound like it is "the Turkish ice-cream" which is a bit misleading. You don't find it everywhere.
You're right! All layers except the topmost layer consist of non-overlapping store paths. It's not one-path-per-layer as there's a hard limit on number of layers, so we smush the packages "deeper" in the dependency tree together within a single layer. There was some work recently where you could specify which paths should correspond to which layers but I can't recall the exact function.
You do have the ability to add a "customisation" layer on top of your image in case you want to create some directories or run arbitrary modifications which does end up as an extra layer which _can_ override the previous layers hence it's always the topmost. But you usually don't need it.
Source: I did a large-ish refactor to the `buildLayeredImage` functions a couple of years ago. My contribution was adding a `streamLayeredImage` function where you can "stream" a derivation to a Docker image on-the-fly without copying any files/layers in the disk.
Hey, author of the library here, thanks for your comment! Disclaimer: It's been more than a year since I've written this, so I might've forgotten things.
This actually teaches me that one thing I should make it clear is this was essentially a weekend experiment from someone who has never used, let alone written a Lisp before.
There's no way it's a production grade software, there are places where the evaluator just borks for valid expressions.
I learned a lot when writing it, so I can probably do a large-ish refactor that would simplify many things and fix the inconsistencies.
> this uses lazy evaluation, because most Lisps use strict evaluation.
The evaluation semantics are pretty weird. It's lazy-ish mostly, but when evaluating there are a lot of places where I unnecessarily force evaluation of things. So I should make the semantics clearer and document them.
> The behaviour of the top-level forms changes when they are wrapped in `begin`
This is a bug, you are right .
> Since this dialect is pure (no side effects)
It's mostly pure. There are a couple of constructs like `assert` and `log` that perform side effects. And also as you mentioned the expressions in a begin can be macros that end up modifying the environment.
> The way `if` handles values other than true/false is backwards compared to most Lisps
You are likely correct and this is a bug!
---
Thanks again of your comments, I'll try to find some time to either rewrite the project, or at least document it better.
I'm sorry in advance for perpetuating the flamewar.
Disclaimer: Turkish here. I do not deny the Armenian Genocide, or think it was right for Azerbaijan to reclaim Karabakh with this way.
You are falling to the same fallacy as the Turkish government:
* Claiming Khojali massacre is a lie, disregarding the documented facts. Do not bring yourself down to the same level as genocide deniers; they will beat you with experience.
* The "they did that too" argument; as if any horrible act legitimizes the other one.
So, it makes a much better discussion if we all agree on documented facts and try to move forward from there (if there is any solution to move forward to). The "Armenian Genocide didn't happen" versus "Khojali Massacre didn't happen" discussion seems childish at this point, and it is not going to help either side in the long run.
As someone who is using NixOS for 8+ years, I do agree with both your problems.
(1) I do find that it's very rare having to implement a low level transitive dependency from scratch (most low-level system dependencies are already there, and for dependencies of a specific programming-language ecosystem you'd usually auto-generate them from things like `yarn2nix` or `poetry2nix`). However, I agree that once you need to do that for non-trivial library it quickly becomes painful and require intimate knowledge of both the build system and Nix environment.
(2) This is my main issue. My workflow is also having a local `nixpkgs` clone, and go find the function and the parameters I can use every time I don't remember how to use it. I also think that it is sustainable. There are many exciting improvements going on with the new CLI, so hopefully we will get nicer error messages and better tooling support in near future.
> but the execution has been a miserable experience for me to the extent that I can't make sense of people who report such positive experiences.
There are pain points, but the advantages for me were indispensable. Being able to pin dependencies accurately, reproduce an exact development environment deterministically, and use the single language to define applications, configurations, and even entire system images is a great benefit that I would need to use 10+ tools with individual quirks otherwise.
I can consider living somewhere else; especially Wellington is a good option as you said. However currently I am happy with my job and living arrangements here, but definitely I will consider them when I want a change.
But honestly, I always thought that those cities had even less variety than Auckland.
One and a half years ago I migrated to New Zealand from Turkey.
* It was almost my first time abroad, my English wasn't great, and I was new to the culture. However I was amazed that how welcoming and patient people were. I hear the opposite from my friends living in Europe and US.
* I found a job while in Turkey, and the company sponsored me for the visa; and since they were an accredited employer the visa process was painless.
* Job variety is definitely small. I think it is not that hard to find _a_ job since there's usually demand for IT; however they are all pretty similar to each other(big finance/telco companies). If you have a specific interest (FP/Haskell and smaller companies in my case) it would be hard to find a job you like.
* Rent is expensive. Almost every one of my single friends flatshare, but I was able to find a one bedroom flat to live with my partner. I pay about 40% of my salary to the rent.
* However I do not think living expenses are too much. Our weekly shopping are usually cheaper compared to Turkey relative to the income. And most of the stuff we like to do for fun is usually cheap or free.
* People are nice. The city feels safe. Nature is great, lots of great hikes just an hour drive from the city center.
Overall; I can not compare with Europe or US since I've never been there, but I'm glad I am here now. And moving here was not that hard, so I think it has everything it needs to be a Tech hub, other than momentum.
I'm just today converted a 300ish lines of Python computer vision-machine learning script to MATLAB. Mind that I'm a long time Python programmer(4+ years), and just used MATLAB once or twice.
But surprisingly, the resulting MATLAB code was fast, clean(cleaner than Python version) and also compatible with vast amaount of machine learning algorithms written in MATLAB(thats the very reason I had to switch to MATLAB).
I always thought that Python can do everything cleaner and more elegant, but I'm sad that in MATLAB, its easier and cleaner.
At least, now I don't need to import numpy, cv2, scipy, scikit-image, scikit-learn, pylab, matplotlib and ipython. Also, installing them was pretty hard too(specially scipy).
A saner approach would be to start with a FFI-friendly language and create bindings. I don't think just being able to use an already written framework in Python is worth the trade-off.