chris_armstrong

Awesome to know with my limited exploit analysis experience that NOP sleds are still a thing

Compared to languages that have a single implementation, have multiple commercial and open source implementations in reasonable states of continuous development seems like a good place to be.

When you look at Elm with similar projects, like Melange or Rescript, they’re all “dead” in the sense that they aren’t the moving targets that most people expect of the Javascript ecosystem.

That said, they are still under active development with their own small communities achieving what they set out to do, and no more. No expansive rewrites or fancy new features.

Compare with Typescript, which always is “improving” because it’s trying to provide type inference around a loose Javascript model, so there’s always more complexity to be added.

There's an alarmist aspect to this article, but there is no doubt that things like ChatGPT will be used to produce an enormous amount of garbage texts that will flood into and destroy the value of content-driven sites like news, recipes, social media, how-to/tutorial, education, etc.

A higher value will be put on socially administered and validated content providers, where reputation will be king.

I think treating PartiQL as syntactic sugar is the mature approach - no one is under any delusions then as to how the database works.

I mostly use it for ad hoc stuff whenever I need to get at something quickly. The SDK interface is horrible in its own right.

(Author here)

I agree: ORMs as I would traditionally think of them, like Hibernate are very mismatched to SQL databases. In this case, Prisma describes itself as an ORM but it maps more like a KV table description with join conditions (I’m not sure how else to describe it).

I’d still argue it’s semantics are more compatible with DynamoDB though, complementing rather than working against the underlying storage model.

It seems like since MacOS X become free that it has succumb more and more to the pressure of a regular release cycle, instead of less, which is the opposite of what you’d expect for an unpaid product.

Why does Apple feel the need to release more and more features at the OS level each year when their customers are only paying for the hardware, not the software?

What's extremely funny about this is that Amazon, Alphabet and Meta are all very much oriented around advertising and data collection (with a bit of product on the side, as a treat to users), and Apple is now ready join the same party after neutering the potential competition in the platforms it controls.

(in fairness, Amazon is really all about AWS, which almost seems like its there to prop up the e-commerce business)

That’s really minimal, even for x11: it doesn’t even do reparenting and setting up window borders or xdamage/xfixes compositing

Surely this is a "Ship of Theseus" type of problem i.e. to achieve this longevity you have to continue maintaining it until it is no longer (philosophically) the server you began with.

Keep its software and configuration practices up to date, upgrade and replace components. Servers that have lasted 10-15 years have rarely done so with at least some maintenance, and the less performed, the accumulated legacy of being out of date is more likely to sink it completely.

Everyone talking about the algorithm being slow instead of wondering why an app needs to do this in the first place.

At the very least, this isn’t hugely useful, and if it was, why can’t it rely on a OS level file search cache to help it?

Yeah there's definitely some interesting stuff in the other blog posts, but oh boy, am I left begging for a narrative

This article is weird linking together many unrelated strands of thought.

Like linking reactive programming to “reactive” UIs, when really they mean UIs that are forgiving to their users instead of breaking down.

Or how by coding on the web we’ve lost the immediacy of a UI that runs on our desktop, and the primitives (like undo/redo stacks) that make desktop user interfaces friendlier, at least without having to build them ourselves.

And that new UI frameworks show up claiming to solve the problems that React creates with complexity, by forgoing the functionality that React provides that they pretend is unimportant by hiding behind toy examples.

There’s actually not much in this article that doesn’t resonate with a jaded millenial like myself who knows their computer history, but could have been expressed more cohesively.

In addition to serverless meaning that you don’t have to worry about the compute layer, I take it to mean also:

• I don’t need to manage the infrastructure for each of the services I depend on • My compute and other services are billed based on usage, not for being switched on • Everything scales up as needed, and just as important, down to zero

I should have been more nuanced on right sizing: if you have a large fleet of servers with homogeneous specs ir workloads, it can be very much worthwhile. The problem with rightsizing is the amount of planning and testing that needs to go into it for production workloads, which is a significant cost in staff time vs the potential savings - this must be thought through. For many workloads its not simply good enough to review some historic metrics and adjust, as there will be implications for baseline and performance under load

Managing cloud cost is much easier if you target it from the beginning.

Having worked in this space, the things that work are mostly centred on making it easier to attribute the source of costs, proactively exploring your bill on multiple dimensions, thinking about the problem early in the lifecycle, and looking for opportunities to delete or turn off unused resources.

The more successful practices that will deliver quickly:

* tagging everything to able to understand who owns what and it is used for

* separating workloads into different accounts (might be easier than tagging and crudely achieves the same objective: attribution)

* turning off unused instances at night in dev environments

* automating the removal of incorrectly tagged resources in non prod environments

* automating image and snapshot cleanup

* avoiding right sizing (it’s trickier than you think and the effort is better spent rearchitecting for more cloud native usage based resource types like serverless)

* exploring your bill and slicing it by service type, account, department and other dimensions you’ve tagged, paying attention to size and trends

* paying attention to network paths (AWS is notorious for expensive outbound and it’s worth understanding how it works and how to architect around it)

* use templates to deploy resources (Terraform/CloudFormation/ARM) instead of console so they’re easier to tear down

* set retention limits on other expensive storage resources (hello CloudWatch Logs)

* being careful with high level services that leverage others under the hood, especially when they’re immature (eg Control Tower + constantly tearing down resources will blow out AWS Config charges)

* using cost alarms

* explore using spot instances, reserved instances or savings plans for EC2 instances

Highlighting specific instances where the working class engaged in learning, when this was clearly not the case generally, is highly disingenuous.

I’d also say that having universities mostly or wholly funded by the state does not remove their profit motive or make it a better place to study: the demand for credentials by the job market will shape their offerings to tailor to it, even if the state can make it a more tolerable experience by sinking more money into it (which would be politically unpopular in the current climate, like the college loan forgiveness proposals floating around)

Credentialism has developed in the crucible of the job market as a response to a high number of job seekers chasing a small pool of desirable jobs. Those that can afford to study longest for the most credentials wins.

(I’m not denying that the need for higher education has increased as industrial production became more complex , but this seems like an adjacent process, and not applicable to all types of study)

Credentialism will only be undone over a long period of very low unemployment where employers will be forced to train employees themselves and will not require as many credentials to sort candidates.

The pleasure of learning in and of itself was always the privilege of a class in society that did not need to worry about educating itself for the purposes of work.

The only thing that is different now is that purchasing an education has become more common, and more of a prerequisite for a job.

The idea that you can simply counter it by convincing universities, which exist to profit from this fact, to slow down and give students more time for leisure in learning, is wishful thinking.

Cameras facilitate making 'the body' a commodity in a way they couldn't in the past i.e. cameras, and the ability to share photos with others are both ubiquitous now.

I thought the article touched on an important point: the reluctance to be nude in public is the commodification of bodies (through photography, social media, plastic surgery, porn), where effectively people drawing a line where they did not have to before. I think people are increasingly aware of this in their interactions in public spaces, especially when so much more of our social interactions are up for commodification through social media and the like (even the commodification of sentiment and political issues which is raison detre for many Twitter personalities, journalists and podcast hosts)

"content" is just calling it what it is - the producer does something (writing) in exchange for money which has an output (content) that valuable to the consumer (publisher).

It's self-serving complaining about your publisher reducing what you do to its commodity form, while at the same time insisting what you do is more than that. Both sides of the transaction are trying to get a better price, and the art of it lies in the mystification (for the producer) or the demystification (for the consumer) of the commodity.

If you want to insist that what you produce for a living be called something other than what it is in a transactional relationship, then you need to do it outside the realm of transactions.

The complaint about "community" and "creator" is fair - but at the same time, it's companies trying to sell the benefits of some underlying thing they've created, by positing the social activity around that commodity as a special property of the thing itself (just like the author saying what they do is more than content).

Quite the contrary: the author intended to do away with the abstraction over indexes that SQL engines provide, so that the developer can code against them directly

This would be the main reason for joining a union (legal support and resume or contract advice) as a developer.

Research their public profiles: my impression is that some are very much in the “employee advocacy” space (providing enterprise bargaining where appropriate), whereas emerging tech unions in the US (particularly those aligned with specific FAANGs) appear to be more about pushing a particular political line than worker representation and support.

True, the problem can be confined to many overtouristed districts, not the entire city, but small places seem to suffer much more

My impression (based on their Readne) is that the author did this not necessarily for readability, but to remove the abstraction that the database engine provides in the form of the query planner.

The developer is then responsible for selecting the index and storing their data appropriately, which gives more predictable performance and makes reasoning about the behavior of the query simpler(for beginners, not necessarily easier).

This is very much in the pattern of DynamoDB (which they cite), which gives highly predictable performance at all scales by removing the query planner layer and leaving the developer to work out what indexes they need, how to mold their data to them, and how too query them.

Only the big cities (eg Paris or London) preserve a sense of a city both maintaining a connection with their past but also still lived in

The comment about “open air museum” really resonates. Increasing numbers of European cities with well preserved districts are so overrun and catered to tourists that any sense of a living city is gone

If you're placing a strong importance on ecosystem, and after something that can be used in a less-OOP / more functional style, it's hard to go past TypeScript (whatever distaste you may have for the dark corners of JavaScript).

A less vibrant ecosystem, but far stronger on the functional and string typing, take a look at OCaml (others have suggested good alternatives like F# or Scala if you want to leverage the existing VM-based ecosystems).

this is such annoying clickbait, of course structural typing can have unsafe behaviours: https://twitter.com/ckarmstrong/status/1536931168654073856?s...

I've used JavaScript and TypeScript professionally for more than 7 years now and I'm still discovering new ways structural typing can break systems in novel ways. It's not like you don't benefit from the reduced need to type everything everywhere, but there are still holes that can leave subtle bugs in your system.