Show newer

to clarify — most of Kazakhstan celebrates new year instead. its aesthetically the same as christmas. we too put up a spruce tree with shiny balls and have a red boomer come home and shower us with gifts. we just don't do that on the birthday of The Dude Who Came Back

Show thread

I've written a tutorial of sorts, showing how to write a streaming XML sitemap scraper using Promistreams! wiki.slightly.tech/books/proje

@mawr Nothing is ever same. It doesn't change anything about the harm that language bashing does, and it absolutely does harm with JS too.

@joepie91 "if you disagree then you can just fork it" is a response that you'd only get from a developer to shut down genuine complaints often made by users who are themselves not developers and never will be developers.

It's a callous cop-out at best and a refusal to acknowledge and address poor design or critically missing features at worst.

I've worked with a bunch of game engines over the years. so far Godot + GDScript is genuinely a lot of fun to work with, it brings back that "small but powerful framework" vibe. Has many quirks and odd decisions (most I probably haven't even encountered yet), but yes, it's fun to work.

Wealthy Americans every Christmas: *watching endless adaptions of a moral fable by a Victorian social critic about how the rich stop the poor from affording necessary healthcare, so that their children die, and how this also damns the rich*

@mawr @serapath (Those are typically also projects where the scope is so limited that running into governance disagreements is *hard*, because there's not much to be governed to begin with)

@mawr @serapath Hm, I'm not sure that's entirely true, I guess it kind of depends on how you define 'fork'. For highly modular code, where a package does exactly one thing, it can make sense to fork it to fix a bug (if upstream is no longer actively maintained) or do some sort of project-specific optimization, for example.

But that's more a 'fork' in the sense of 'making a derived project', not so much in the sense of 'supplanting the original for community adoption'.

OH "Wait, the bus is now more luxurious than my car? I don't have individual seat heating in my car!"

It occurs to me that this is rarely said out loud, but it probably should be:

The ability to fork open-source software is important, *but* the idea of "if you disagree then you can just fork it" is basically a lie. It has never worked that way and it will never work that way.

In reality you're dealing with project governance and so there are a lot of social factors (community support, motivation to 'compete' with the established name, etc.) that are critical to not having a fork wither on the vine.

And it's very difficult to pull that off, and usually requires a long history of growing resentment about the leadership of the forked project. This means a fork is rarely the best solution.

vaguely spicy take 

@hazelnot My experience is that, at least in tech jobs, the more uncompromising you are, the better you tend to get treated by bosses. Similarly, charging more causes customers to be more respectful of your time...

@raito No conditions whatsoever, including and up to supporting `null` values, as there is no serialization step involved anywhere (unless you add a serialization stream, of course).

You represent the processing steps as a linear(-ish) Promistream pipeline in your code, but behind the scenes that essentially gets converted into a long chain of Promise handlers, so anything that can go in a Promise (which is everything) can go into a Promistream too :)

vaguely spicy take 

@hazelnot They could, but it would be unreasonable

@raito So Promistreams are agnostic to the values that go through them; you totally could use them to design some sort of streaming component system (by streaming through component-shaped objects), but Promistreams *themselves* do not do anything with components, and it wouldn't be directly in scope.

Someone actually compared Promistreams to Rx.js earlier today, in concept, so you're probably not far off with your idea :)

(There *is* a plan to write an Rx.js adapter stream which can convert between Rx.js and Promistreams bidirectionally, so if such a component system already exists based on Rx.js, then Promistreams could plausibly interoperate with it)

vaguely spicy take 

@hazelnot The actual rules you have to comply with (as enforced by eg. tax authorities) generally just specify that it must be concretely useful to the job in some way. This is trivially satisfied by hacker events if you're remotely working in tech.

Crucially, that specifies what property the trip *must* have. It doesn't specify what property the trip *must not* have. Whatever rules executives layer on top of that is 100% their own ideology, and that is on them.

(Also, it's standard practice for people to get completely and utterly drunk at 'boring' industry conferences too, so it's not like "injecting some kind of fun into events" is exclusive to hacker events anyway)

Maybe we should stop calling them *Notifications* and instead refer to *Interruptions*.

"Working on some stuff so I've turned off interruptions for a while."

"Right on."

vaguely spicy take 

People joke about "expensing hacker events as work trips" but actually I think that's genuinely a reasonable thing to do, even under the 'conventional' understanding of what constitutes a 'work trip' (for training and education).

There's no rule that says a trip must be boring to qualify as "materially useful to your job"! That idea is just some puritan(?) ideological nonsense, it has no bearing on how the world works.

Promistreams are now officially in beta! :boost_requested: (Which mostly just means I have added a little infobox at the top of the page :blobcatgiggle: )

wiki.slightly.tech/books/proje

Basically, they're streams for that are actually nice to work with, have first-class Promise support, handle errors correctly, handle concurrency reliably, interoperate with other stream implementations, and just generally make more sense than Node streams.

You can use them for streaming data, but also for things like task queues or distribution patterns. They can work in any JS environment, and are not limited to Node.js. More documentation will become available soon (especially for more complex cases), but the basic stuff is already explained at the link.

Please give them a try and let me know how it went, and whether you ran into any issues!

Show older
Pixietown

Small server part of the pixie.town infrastructure. Registration is closed.