Lyapunov sounds a good tool but the README reads so LLM-generated and with little love that I am not bothered to look further into whether this is solid or not.
Add »hacking the self-driving car« to the equation and you get the perfect classical-cyber hybrid crime. Afterwards, the poor waymo cannot remember what even has happened. That's spy film material :-D
I find the arena experiment very interesting. If done right, whole programs can be structured as as a set of arenas. I've read some things on arenas here such as https://news.ycombinator.com/item?id=37670740
Once allocators in general click, memory management in C becomes a total breeze.
Combined with typed fat pointers (slices and strings), typed hashmaps and stack-trace-assertions, C in general becomes quite nice. The rest is compiler flags.
Go solves this by being a better language out of the box, but with the Wirthian aspects removed they feel very similar. Perhaps not so surprising.
I am a low-level zig guy right now too. I have been around for a long time, and it’s funny to see arenas come back into vogue as a solution to nearly everything.
Arenas are great for avoiding allocations per tick/request/frame/layer. No symmetric free() to bracket lifetimes! They have a purpose, and we always knew that.
But by definition, your program is over-allocating as a tradeoff. Makes a ton of sense in certain use cases. However, we didn’t invent garbage collection and borrow-checking and realloc() just to publish papers ;)
Half of my time programming zig is spent considering allocation strategies. That’s a feature. “Where are the bytes?”
I wonder if they can solve the "ecosystem fracture" issue by borrowing the bubble concept from e.g. testing/synctest. The way the synctest API works is by creating a "bubble" around the test harness and the code under test such that the standard library's time package behaves differently, but only for the code running in the bubble.
So, maybe we could also have allocator bubbles, where code running inside the bubble is just as allocator-naive as any other Go code, but when it allocates (make/new/pointer escape), it uses the bubble's allocator instead of the default one.
The big problem I can think of, though, which doesn't apply to time bubbles, would be that pointers drawn from that allocator might escape the bubble (e.g. by assigning them to a longer-lived struct field). It's possibly something that can be detected by the runtime, but because the API is non-invasive by design, it's not something that will be apparent to the programmer when looking at the code.
Long-distance shipping is even a pain in the (so-called) developed world, for instance from Europe to the US. As soon as your shipping value exceeds a treshold (IIRC about 1000€), you have to electronically declare the customs. There are agencies specialized to do this for sth like 20€ per shipping just because it is not reasonable to get all the accounts if you do it only once in a while.
However, in my experience, "ordinary" parcel shipping (like DHL) won't do this shipping either any more: You have to switch to the express ones (like DHL express, UPS, FedEx) even if you don't intend to do any express. The difference is easily 40€ vs 400€ for shipping a shoe box!
If you ship anything slightly larger then a shoe box and slightly more expensive then a notebook, think twice whether you don't want to accompany the freight with a seat in the commodity class in some airplane. It can easily be cheaper.
No kidding. My old company needed to replace an aircraft engine part for a customer in Japan, and it ended up being something like a third of the cost and time to give one of our mechanics essentially a weeklong vacation rather than ship it (as a bonus, he was able to hand carry the broken part back for failure analysis, rather than having to deal with equally expensive and slow return shipping).
An airline pilot told me his only ever engine-failure event was on a flight from Dubai to Beijing, they were over half-way when one of the four engines failed. Company told them to return back to Dubai, logistically they were never going to get a new engine to Beijing
> As soon as your shipping value exceeds a treshold (IIRC about 1000€), you have to electronically declare the customs.
The threshold is zero in my experience. I volunteer with a small non-profit publisher, and last year we shipped a few hundred magazines to Europe but with the wrong customs labels. These are black-and-white technical journals shipped in clear plastic, so even with missing labels, they very obviously have almost zero value.
But because we had the wrong customs labels, about half of them were held at the border and our members had to pay the duties themselves, since it was too late for us to pay them. I think that one member had to pay almost 20€: 0.20€ in VAT, plus 19€ in "fees". We sell the issues for $4.50 each (plus shipping), so it was quite a surprise when we started hearing about how high the fees were.
This isn't due to inexperience either, since we've shipped ~1k copies to Europe every year for over 40 years. But we had just switched shipping providers, and our new provider had just written "magazine" as the label without any further details. For the next shipment, we added a proper customs code and prepaid the duties where possible, and that seems to have solved the problem.
> This shows that "extremely portable" is actually marketing for "It supports a number of platforms. In my opinion, this number is big".
The number might just be zero - did anyone check if this compiles? I am trying to track down where the function `sp_mem_allocator_alloc_type` is defined (used in 3x places) but it doesn't appear in the GH search results.
I'm not going to clone and build this (too dangerous).
Only if you want to move from MacOS Sequoia to Tahoe. Tahoe has the Liquid Glass stuff that people don't like as well as other UX changes that have been controversial.
Matlab inspired the scilab ecosystem, which is based on numpy, scipy, matplotlib, pandas. This was a major driver for the data science industry for a decade before AI kicked in and tensorflow, etc. was also built ontop of these libraries.
While I personally try to avoid contemporary matlab at any cost, the open source ecosystem is great and matlab would be my go-to tool if they would not exist.
scilab is not based on numpy/etc. However, matlab was certainly an inspiration for the scientific python stack in early 2000s. I myself started contributing to numpy and matplotlib by adding missing features I needed to move away from matlab in 2006 or so.
I just gave Zulip a try with a team of 3. I loved the UI because I spent years in pain finding things in big Slack and Mattermost installations (big = 30 users, nowhere near enterprise-level). For my two junior colleagues, instead, Zulip was too complicated. We evventually switched over to Discord.
I highly recommend Zulip to anybody who faces the problem that the concept of threads and channels is not a good fit to their mental model of tasks and groups in teams.
reply