Hacker Newsnew | past | comments | ask | show | jobs | submit | el_oni's commentslogin

We started doing sourdough in lockdown for 1 reason. The shops nearby were out of yeast. kinda limits your options

Beautiful, I'm currently deep into getting our data into iceberg from firehose and I'm really curious what metadata is written, are bloomfilters being written for the columns i want? Has my compaction and sort jobs helped min-max statistics on those columns?

Will take a look when i get to my laptop!


They also point south. If you changed which end of the needle was painted red it would be just as useful for orienting to the south as existing compasses are for facing north


My partner and i used to harvest medlars from a community garden. We made medlar jelly from them when they had bletted. It kinda tasted like tea. Must be the tannins. We ended up making a sweet chilli sauce from it when we still hasnt eaten it when our chillis became ripe the following summer


There is a difference between dark roasts from a specialty coffee roaster and a dark roast from Starbucks.

The specialty dark roast will have notes of cookies, chocolate, nuts. Lots of brown roasty flavour.

Starbucks tastes bitter. With very little nuance. (Unless you cold brew it, then you can leave most of the bitter behind)


Rustler catches panics before they crash the VM and raises them on the elixir side as an exception. So your process might crash but the vm wont


That's a neat way to get corrupted state in your application, especially when users of said language don't realize that their language has exceptions.

I wrote this recently about Go, but it equally applies to any Rust application that tries to recover from a panic.

https://kristoff.it/blog/go-exceptions-unconvinced/


I don't think this is right. The process will crash, and the Supervision strategy you are using will determine what happens from there. This is what the BEAM is all about. The thing with NIFs is that they can crash the entire VM if they error.


Erlang's (Elixirs) error management approach is actually "Let it crash"

This is based on the acknowledgment that if you have a large number of longer running processes at some point something will crash anyway, so you may quite as well be good at managing crashes ;-)

https://dev.to/adolfont/the-let-it-crash-error-handling-stra...


Yes, but that's not Rust's error management strategy. Most Rust code isn't written with recovery from panics in mind, so it can have unintended consequences if you catch panics and then retry.


This is terrible, actually. And I've run into it, causing a memory leak.


How so? The whole point of unwinding is to gracefully clear up on panics, how did it peak for you?

It's also not like there is much of a choice here. Unwinding across FFI boundaries (e.g. out of the NIF call) is undefined behaviour, so the only other option is aborting on panics.


Yes. Abort early in unit tests, core dump so it never makes it to prod


The panic is converted to an Erlang error exception. You have to explicitly ignore it to make unit tests pass in spite of it.

I am still interested in the situation you observed.


It's sufficiently well known that as a British 30 something I understood what was being alleged just from the headline


Very cool, this should help me to be able to separate my different testing environments.

Thanks for sharing!


The boring company released a flamethrower[0] presumably to raise some capital.

[0]https://www.boringcompany.com/not-a-flamethrower


I've been using d2 recently [0] It's similar enough to mermaid but with the CLI you can output svg and png and have some decent looking diagrams.

[0] https://d2lang.com/


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: