> Turns out sometimes you gotta use these "orphan" functions even though they logically belong to a certain type (in this case, why isn't tuple_size called like Tuple.size or something?)
tuple_size/1 is a guard, and guards are built-in. The compiler itself uses them. Unlike regular functions, you are allowed to use guards in a function head, like:
def foo(my_tuple) when tuple_size(my_tuple) == 3 do ...
Ahh, that's it. I said in a sibling comment that I had no idea why it was like that. But reading this made me realize that at one point I did know why! Completely forgot this bit of knowledge in the last year of not using the language.
Oh yeah, FWIW a "built-in" function or macro just means it's a part of the Kernel module, which is automatically required+imported in Elixir modules. So it's not orphaned, it's just in the one special module that gets brought in by default.
> ...listing any given prefix is essentially constant time: I can take any given string, in a bucket with 100 billion objects, and say “give me the next 1000 keys alphabetically that come after this random string”.
I'm not sure we agree on the definition of "constant time" here. Just because you get 1000 keys in one network call doesn't imply anything about the complexity of the backend!
The technical implementation is indeed impressive that it operates more-or-less within constant time, but probably very few use cases actually fit that narrow window, so this technical strength is moot when it comes to actual usage.
Since each request is dependent upon the position received in the last request, 1000 arbitrary keys on your 3rd or 1000th attempt doesn't really help unless you found your needle in the haystack in that request (and in that case the rest of that 1000 key listing was wasted.)
You’re assuming you’re paginating through all objects from start to finish.
A request to list objects under “foo/“ is a request to list all objects starting with “foo/“, which is constant time irregardless of the number of keys before. Same applies for “foo/bar-“, or any other list request for any given prefix. There are no directories on s3.
> Don’t do it. Really, don’t do it. Anyone that has been giving tech talks for a while now knows not to do it. Don’t do it.
A few years ago, I found myself in San Francisco right on time to see Larry Wall give a talk announcing the release of Perl 6, and showing off some of its (abundant) features.
Larry Wall did the entire presentation in Vim, including live coding.
It's not that no one can pull this off, it's just that most of us aren't them :)
> It's not that no one can pull this off, it's just that most of us aren't them :
Having just done a talk at FOSDEM 2024 the main reason not to do a demo is that the slots in most devrooms are really short. In the monitoring devroom talks were in 30 minute slots, which included audio setup, talk, questions. Live demos can really enhance a presentation to developers but trying squeeze them into an already short slot can muddy the message. I would rather point the audience to examples they can run themselves.
On a related point, I find recorded demos pretty horrible. The pleasure in demos is seeing the presenter work fluently with technology and the audience at the same time: "the achieve of, the mastery of the thing!" as Gerard Manley Hopkins memorably phrased it. [0] It's showmanship and existence proof combined--and the most powerful rhetorical device to make technical points. The best ones are legend. [1]
In the Python world, James Powell is famous for breezing through a combination of vim (the editor) and wat (the tutorial by absurd) with a lot of custom command line tools and even examples that feel at the same time immoral, hilarious, and perfectly crafted. There’s a reason his GitHub handle and his company are called “Don’t use this code.”
He’s switched to analytical SQL lately, which is less prone to comedy but still very virtuoso.
> It's not that no one can pull this off, it's just that most of us aren't them :)
The issue is that live demos require INSANE amounts of prep.
You have to go over it. Then you go over it again. Then you go over it again with a stopwatch. Then you go over it again. Then you kill the network and go over it again. Then you go over it again with a stopwatch. Then you go over it with a friend with a stopwatch. Then you go over it again. Then you go over it with a friend but you use the stopwatch with no network. Then you go over it again. Repeat until you feel like you're in Groundhog Day. Then go over it one more time.
By the time you give the demo in front of people, you should be so damn bored with giving it that the only reason you want to give the talk is to see the audience reaction.
In my experience (I gave a demo as part of a talk today! It went great!), you want your code to be reliable (obviously... a 1 in 5 failure rate will bite you back on demo day), require as little thinking as possible (that can be worked around with increased automation, but if you automate all the things, you might as well be showing a recording), and rehearse things extensively (this applies to every part of a talk anyway).
Also rehearse on a specific commit/build. I've seen so many cases where a feature or two were added since rehearsal and about was introduced into the demo path. If you do want to fix something for the demo run through your rehearsal another few times on the new commit.
Some of his live demos take my breath away. I have to make notes to myself like "click the 'upload' button" so I don't forget during a presentation. It's like my brain switches to a mode where simple tasks are impossible
Yeah, there's a certain demo gods category who can usually make it work. But it's also sort of showing off. And I'm also somewhat unconvinced about how much demos add to a presentation a lot of the time.
Larry is a genius and perl6 (now raku) does indeed abound with features. The idea aiui was to minimize the need for external dependencies in most code bases and to bring together all the features into "v1" rather than suffer from bolt on features and shoehorned syntax down the road.
This is pretty much a myth. Both run a different kernel. macOS used be known to have a network stack (and maybe some stuff like a virtual file system) from freebsd but I am pretty sure most of the code has been replaced by now.
Having some BSD userland binaries doesn't make your OS a BSD. Otherwise Windows is just a fork of curl.
Last I checked, Darwin sources for tcp still look a lot like FreeBSD circa 2000 plus some Apple patches (MPTCP). No syncookies in 2024, because FreeBSD added those months after Apple forked the stack.
I argue that having a BSD license (in Darwin), BSD heritage (NeXTSTEP, FreeBSD, briefly NetBSD), and a mostly BSD userland 20+ years into the project makes this OS a BSD.
Don’t forget its two friends — the long-handled Torx and the screwdriver with the 10M resistor and the alligator clip, to bleed the charge out of the CRT.
Fun machines. I still have two SE/30s, including my upgraded SE from childhood!
> At release Netscape Navigator 1.0 competed against NCSA Mosaic. Over Mosaic, Netscape offered the ability to see documents and images as they load, loading both images and text at the same time, support for JPEG graphics, document caching, a friendlier GUI with more configuration options, and hierarchical bookmarks.
This leaves out a huge differentiator -- Netscape supported background images. Every site looked blander in Mosaic (even if it were a lot easier to read). The other features TFA mentions are great but background images were the origin of "This site is best viewed using XXXX".
tuple_size/1 is a guard, and guards are built-in. The compiler itself uses them. Unlike regular functions, you are allowed to use guards in a function head, like:
Official docs: https://hexdocs.pm/elixir/1.16.3/patterns-and-guards.html#gu...