These are spoofed packets for SYNACK reflection attacks. Your response traffic goes to the victim, and since network stacks are usually configured to retry SYNACK a few times, they also get amplification out of it
There is a solution to that, but it requires these companies to implement source address validation. If your ISP is on the list, maybe complain about it.
personally, i like that raku goes the other way, with exported bits of the interface explicitly tagged using `is export` (which also allows for the creation of selectably importable subsets of the module through keyed export/import with `is export(:batteries)`/`use TheModule :batteries`, e.g. for a more featureful interface with a cost not every user of the module wants to pay).
it feels more natural to me to explicitly manage what gets exported and how at a different level than the keyword used to define something. i don't dislike rust's solution per se, but if you're someone like me who still instinctually does start-of-line relative searches for definitions, suddenly `fn` and `pub fn` are separate namespaces (possibly without clear indication which has the definition i'm looking for)
Actually, a module can implement any export heuristics by supplying an EXPORT subroutine, which takes positional arguments from the `use` statement, and is expected to return a Map with the items that should be exported. For example:
sub EXPORT() { Map.new: "&frobnicate" => &sum }
would import the core's "sum" routine, but call it "frobnicate" in the imported scope.
Note that the EXPORT sub can also be a multi, if you'd like different behaviour for different arguments.
neat! i've never needed more than i could get away with by just sneaking the base stuff into the mandatory exports and keying the rest off a single arg, but that'll be handy when i do.
Oh nice, I didn't know about that one! It's interesting how many solutions are in this space; aside from Destructure[0] and shorter_maps[1] I also know about shorthand[2] and synex[3].
There was also a relatively popular fork shorter_maps [0], mentioned in the blog post above. My motivation for implementing es6_maps instead of using/updating shorter_maps was (I'm copying from my post in the Elixir forums [1]):
1. I do firmly believe this is a good language feature and a very natural extension of map literals syntax;
2. at the same time, being a language feature it should be simple - es6_maps works only with atom keys and has no extra features over the key expansion.
Point 1 is additionally reinforced by how easy it was to introduce to the compiler - I’m injecting just 9 lines of simple code, while parser and lexer already accept short-form maps without modifications.
> I think the formatter plugin is going to give someone insane amounts of regret one day
The formatter plugin features a "reverse" flag exactly to prevent any kind of regret like that. You can reformat your code automatically to remove all shorthand maps and remove the dependency in a couple simple steps.
> I’d really encourage you to put a note at the top of the readme that this shouldn’t be used in production code.
Noted, although I do think it's production ready. I'm going to keep updating the library if or when a new version of the Elixir compiler breaks it, and it does feature an easy way out in case I disappear.
And why does it seem fair enough? The garage door is mine, not Chamberlain's (although that starts to be more and more debatable the farther into enshittification we go).
Cursor Settings -> Agents -> Applying Changes -> Auto-Accept on Commit