auxiliarymoose

The crazy thing is that today the JavaScript standard library is very robust, and yet the culture of pulling in a ton of dependencies persists. It's so much easier to develop code against a stable and secure platform, yet it seems the choice is often to pull in hundreds of bits of code maintained by many different parties (instead of doing a little more in-house).

They are reasonably consistent because there is a de-facto reference implementation (Adobe Acrobat) which, if your implementation does not match exactly, users will think your implementation is broken.

There isn't such an implementation for SVG.

Also remember that if the untrusted SVG file is served from the same origin and is missing a `Content-Disposition: attachment` header (or a CSP that disables scripts), an attacker could upload a malicious SVG and send the SVG URL to an unsuspecting user with pretty bad consequences.

That SVG can then do things like history.replaceState() and include <foreignObject> with HTML to change the URL shown to the user away from the SVG source and show any web UI it would like.

Yes. Much better to handle all untrusted data safely rather than try to transform untrusted data into trusted data.

I found this page a helpful summary of ways to prevent SVG XSS: https://digi.ninja/blog/svg_xss.php

Notably, the sanitization option is risky because one sanitizer's definition of "safe" might not actually be "safe" for all clients and usages.

Plus as soon as you start sanitizing data entered by users, you risk accidentally sanitizing out legitimate customer data (Say you are making a DropBox-like fileshare and a customer's workflow relies on embedding scripts in an SVG file to e.g. make interactive self-contained graphics. Maybe not a great idea, but that is for the customer to decide, and a sanitization script would lose user data. Consider for example that GitHub does not sanitize JavaScript out of HTML files in git repositories.)

You can use `&` operator to combine types. Works for adding fields, making branded types, etc.

Agreed on native HTML+CSS+JSDoc. An advantage in my use-cases is that built-in browser dev tools become fluid to use. View a network request, click to the initiator directly in your source code, add breakpoints and step without getting thrown into library internals, edit code and data in memory to verify assumptions & fixes, etc.

Especially helpful as applications become larger and a debugger becomes necessary to efficiently track down and fix problems.

This is how I develop web software, and I've found it productive and maintainable.

A bonus of this approach is that it clearly delineates what type information is available at runtime, vs what type information is just a comment. (especially useful when working with serialized data).

I also like that it generally means all of the preconditions and postconditions for functions are in a single place (both the prose and the technical information are in the JSDoc comment), keeping the code itself low-noise and boiled down to its essence, and providing a natural place to write example inputs and outputs to guide usage.

As for generic types, I use them extensively, and this is made less verbose e.g. on function calls by using an @type annotation on the function which accepts a TypeScript signature without needing separate @template + @param annotations.

It's awesome stuff, and I'm happy that TypeScript works so well with JSDoc!

Fun will be prohibited until morale improves.

Much of the challenge in JS today is due to unnecessary packages, build systems, and workarounds found throughout blogs and forums which were reasonable 5-10 years ago but aren't really needed today. Unfortunately, LLMs tend to output old-fashioned JS.

With (almost) everyone using an up-to-date standards-compliant browser, you can sidestep most of the complexity and weirdness by just using the standard library and ES Modules (instead of frameworks, libraries, build systems etc.) and an IDE with good intellisense + inline documentation lookup.

MDN documentation is good and up to date overall, but I'm not sure there is a good overview/entry point resource that is up to date as of today... maybe I'll have to write it!

It is also (nearly) impossible to completely crash a web page. There isn't a main loop that can panic out. No matter where an exception gets thrown, the overall application keeps going and responding to events.

Can't access a network resource? API returns an unexpected error? Library crashes? Browser extension breaks something? Doesn't matter. The user can still view and scroll the page, and the rest of it will probably keep working, too.

Yeah, I was one of those schmucks that used sympy / python instead of mathematica in my physics coursework. Policy was "mathematica is recommended and supported, but you can bring your own tools if you want to and can make them work."

In retrospect, doing the work in mathematica would have probably stretched my brain more (in a good way!) since it provides a different and powerful way of solving problems vs other languages...maybe I'll have to revisit it. Perhaps even try advent of code with it?

While python did get the job done, it feels like the ceiling (especially for power users) is so much higher in mathematica.

You can accomplish fork-join, data parallelism, and cancellation of task trees in a with `errgroup` in Go (which provides a way to approach structured concurrency).

So at least those are a subset of Go's concurrency model.

But how does one actually do that? What does the architecture and code look like?

But how does one communicate and synchronize between tasks with structured concurrency?

Consider a server handling transactional requests, which submit jobs and get results from various background workers, which broadcast change events to remote observers.

This is straightforward to set up with channels in Go. But I haven't seen an example of this type of workload using structured concurrency.

Agreed. Rob Pike presented a good talk "Concurrency is not Parallelism" which explains the motivations behind Go's concurrency model: https://youtu.be/oV9rvDllKEg

Between the lack of "colored functions" and the simplicity of communicating with channels, I keep surprising myself with how (relatively) quick and easy it is to develop concurrent systems with correct behavior in Go.

Writing "append(s, ...)" instead of "s = append(s, ...)" results in a compiler error because it is an unused expression. I'm not sure how a newbie could make this mistake since that code doesn't compile.

For me at least, I find it easier to see the shape of algorithms, control flow, and expressions when the variable names are concise. But this also might be because I have found Go to fit my use-cases and thinking style well, and Go programs tend to follow this naming convention.

For example, if I have a struct `PageEntity` with a field `Id`, and I am iterating over a slice of such IDs, I would prefer using `pid` instead of `pageEntityId` as the variable name. But Java APIs and conventions tend to use these longer names, so I find it takes more thinking to remember the different names instead of quickly seeing the behavior of code at a glance.

Java also tends to have a lot of inheritance which results in these long glued-together names and makes it harder to follow program flow because behaviors get introduced in multiple different places (i.e., it has the opposite of locality of behavior).

But those are just my opinions and experiences! I know many people love Java, and it is a versatile and powerful language.

I tried to check in on Java recently but got a NullPointerException when using the AbstractSingletonProxyFactoryBean !

I mean, the software I develop is the system of record for the engineering and development of medical devices (and aerospace, automotive, industrial, etc. systems). So pacemakers and aircraft are relevant examples.

I hadn't heard about the MySQL layoffs. I hope the affected people find good new opportunities.

High quality writing (e.g. MDN Web Docs, Go Documentation, internal docs) does not have a tendency to include mistakes or incorrect reasoning because it comes from a place of clear thinking and goes through a continuous process of peer review and improvement.

LLMs outputs are, at best, first drafts that have not been reviewed or revised, and they certainly do not have analytical reasoning behind their content.

I am not claiming that my domain is uniquely challenging, but the statements I made are factual for my work (and likely many adjacent fields, too).

Would you trust your life to a pacemaker or aircraft control system designed and manufactured quickly by people without a correct understanding of what they are developing, working purely off of information from the Internet and other semi-public sources? I wouldn't. But maybe you are braver than me!

Yeah, I will say it provides a good excuse to leadership & external stakeholders for fixing technical debt and working cross-functionally! Making infrastructure "AI-ready" and all that.

I imagine more of the benefit of AI will come from companies prioritizing infrastructure and effective organization than from the technology itself.

I try them from time to time, but I have yet to see AI models produce a useful output for my work. The problems I work on are not well-represented in training data and internet-based resources, and correctness matters far more than speed.

For my work, it's important to form strong and correct mental models of complex systems so I can reason about them well. It's more about thinking and writing clearly than anything else. LLMs tend to include subtle mistakes or even completely incorrect information (and reasoning!) which disrupts this process.

On the creative industry side...well, you can produce some results that look fine by themselves, but producing large-scale cohesive artwork (games, movies, etc.)? It's mostly human elbow-grease for the foreseeable future.

> Today we have AI models that can already do as good, almost as good, or even better than the average human in many many tasks, including the ones you mentioned.

We really don't. There are demos that look cool onstage, but there is a big difference between "in store good" and "at home good" in the sense that products aren't living up to their marketing during actual use.

IMO there is a lot of room to grow within the traditional approaches of "yesterday" - The problem is that large orgs get bogged down in legacy + bureaucracy, and most startups don't understand the business problems well enough to make a better solution. And I don't think that there is any technical silver bullet that can solve either of these problems (AI or otherwise)

Decision-making in organizations is definitely a hard problem.

I think an uncomfortable reality is that a lot of decisions (technology, strategy, etc.) are not optimal or even rational, but more just an outcome of personal preferences.

Even data-driven approaches aren't immune since they depend on the analysis and interpretation of the data (which is subjective).

Some off the top of my head...

- Instead of trying to get LLMs to answer user questions, write better FAQs informed by reviewing tickets submitted by customers

- Instead of RAG for anything involving business data, have some DBA write a bunch of reports that answer specific business questions

- Instead of putting some copilot chat into tools and telling users to ask it to e.g. "explain recent sales trends", make task-focused wizards and visualizations so users can answer these with hard numbers

- Instead of generating code with LLMs, write more expressive frameworks and libraries that don't require so much plumbing and boilerplate

Of course, maybe there is something I am missing, but these are just my personal observations!

Super cool, thanks for sharing!

This is one of the reasons I am so skeptical of the current AI hype cycle. There are boring, well-behaved classical solutions for many of the use-cases where fancy ML is pushed today.

You'd think that rational businesses would take the low-risk snooze-fest high-margin option any day instead of unintelligible and unreliable options that demand a lot of resources, and yet...

And in Go I can build a production-ready HTTPS (not just HTTP) server with just the standard library and a few lines of code. (0 packages).

That Rust does not have standard implementations of commonly-used features (such as an async runtime) is problematic for supply chain security, since then everyone is pulling in dozens (or hundreds) of fragmented 3rd-party packages instead of working with a bulletproof standard library.

You can sorta think of `satisfies Foo` as "the type is exactly the literal value, but also make sure the value could be used in the place of a Foo"

I think remote climate controls in a car are an ideal use-case for a simpler architecture.

Consider WhatsApp could do 2M TCP connections on a single server 13 years ago, and Ford sells about 2M cars per year. Basic controls like changing the climate can definitely fit in one TCP packet, and aren't sent frequently, so with some hand-waving, it would be reasonable to expect a single server to handle all remote controls for a manufacturer for all cars from some year model.

Or maybe you could use wifi-direct and bypass the need for a server.

Or a button on the key fob. Perhaps the app can talk to the key fob over NFC or Bluetooth? Local/non-internet controls will probably be more reliable off-grid... can't have a server outage if there are no servers.

I guess my point is if you take a step back, there are often simple, good solutions possible.

Ah, thanks! Hard to keep up with this stuff. Next thing you know the boffins will tell us we need to switch to rot104 or even rot208 because of "post-quantum cryptography" or something.