HN user
https://www.bryanpg.com/
Currently working on: https://www.bryanpg.com/games/pragma_twice
My example was contrived, I'm sure some smart people could come up with a SQL-esque language that is even more readable to non-technical folks than programming syntax. At a certain point though, your layman has to know the "atomic" (as in, you can't break them down further) mathematical concepts like "functions" and "infinity":
`sum function(x) from x=0 to x=infinity`
No, the problem with mathematics is that it is basically its own language separate from your native tongue. You have to learn dozens of symbols and greek letters and such and memorize what their meaning is in the context of mathematics in order to "follow" a mathematical conversation.
Mathematics would be much more approachable if it just used plain English like `sum(0, Infinity, my_func)` instead of a big Greek sigma with nested function nomenclature. But on the flip side, mathematics being its own language means that a mathematician from any country can read and understand mathematics from a different country without needing to translate words such as "sum" and "infinity"
When I was typing "ssh-copy-id" I typed "ssh-c" and then hit tab... I was disappointed
And yet you're using one
I'm using a TS type stripper API from a go package inside the server. I'm not actually doing any "bundling" which implies resolving imports, tree shaking, combining multiple files into one, minification, uglification, etc. I'm strictly stripping out types and serving what's left directly to the browser. This costs less than 1ms of cpu time on a cold load (and usually costs nothing because of front-end caching/etags)
Look, I don't want to argue with you. Just sharing my setup. I develop medical device software which means dependencies are very expensive because they incur regulatory burden. SBOMs and associated CVEs have to be tracked and reported to the FDA. My TS/golang stack means:
- My docker images can be from scratch or from busybox with a statically linked go binary
- My frontend can be vanilla TS with zero dependencies (npm or otherwise)
- Debugging is dead simple: set breakpoints directly in dev tools and it's WYSIWYG (no map files needed, etc)
- Feedback is instantaneous. If I change a file in TS and hit refresh, the change is reflected instantly (compare to bloated Vue/React shops I've seen where every change requires a 10 second frontend compile pipeline to run before you can get feedback in the browser)
You don't need a bundler, just a type stripper. And yeah you need a middleware to perform the type stripping, the server won't do it automatically, but it's like 10 lines of backend code. The basic flow would be something like:
1. Browser requests /js/foo.js
2. Server middleware checks if /js/foo.ts exists
3. If yes, server middleware strips types from the file before returning it
In golang I use the go package github.com/evanw/esbuild[1] to do type stripping on the fly. The middleware looks like this:
``` return esbuild.Transform(string(fileBytes), esbuild.TransformOptions{ Loader: esbuild.LoaderTS, Format: esbuild.FormatESModule, }) ```
It only takes a few microseconds and I don't need any bundlers or tsc or anything like that. Everything on my frontend is 100% vanilla TS; I make changes directly to TS and then hit refresh in my browser and the changes are reflected instantly without needing a bundler or even node/npm for that matter. Note: for this setup to work, your front end TS has to use ES modules import/export which browsers natively support. If you try to use CommonJS or something like that, you would start needing a bundler again because browsers can't resolve "require" statements.
In node it should be even easier than Go because Node added native type stripping starting with v22[2]
But even on older versions of Node, a type stripping middleware would still be very easy to implement[3][4].
[1] https://pkg.go.dev/github.com/evanw/esbuild
[2] https://nodejs.org/api/module.html#modulestriptypescripttype...
Why doesn't it make sense? I actually do exactly this in my own setup, but with golang instead of Node.
Presumably Node is the server (back end), and when the browser requests a TS file, Node is stripping the types before serving it to the browser.
Not everyone is building complex UIs like google sheets. Most people are building static pages with a sprinkle of interactivity, or maybe form pages for doing CRUD.
Web components, invoker commands API, etc.
Even better: vanilla TypeScript + golang middleware (esbuild) on the backend that converts to JS on the fly. Like vanilla JS but with all the benefits of a type system and no bundler or npm required.
Dr. Bernstein has long argued this and documents it extensively in his book "Dr. Bernstein's Diabetes Solution"[1]. The main reason being that muscles act like natural glucose sinks that drain sugar directly out of the bloodstream, bypassing the liver, so more muscles = more glucose control.
I highly recommend the introductory chapter to "Dr. Bernstein's Diabetes Solution" by the way, even for non-diabetics. It's basically just the "Life and career" section of his wiki page, but in way more detail -- a really interesting biographical account about an industrial engineer doing diabetes self-experiments with a glucose meter he procured through his wife and going up against the medical community/orthodoxy and failing, only to finally break through when he got a medical degree late in life. I could probably upload and link to just that section if people are interested.
The required technology is not possible - 3D printers read code, not intent; they cannot tell what a shape is for.
"Anthropic announces Project Disarm, a new model designed for 3d printer manufacturers to quickly infer whether the intent of an stl file is a weapon. The printer first submits the job to the cloud, and only after it's approved will it print."
Not that I want this future, just that I can imagine it.
So I guess this is a competitor to Electron?
Go needs a good static analyzer to detect potential nil pointer dereferences. That would help identify and eliminate any unnecessary nil checks. .NET has a good one for C#.
Ban infinite scroll? Sounds like a slippery slope and also hard to enforce. I don't even know how you would craft such a law.
Knowing how to make a nuclear weapon isn't hard (at least basic uranium gun-style fission ones). It's the engineering and execution that's hard (actually producing enriched uranium, etc). It's not like the only thing holding back Iran from making a nuclear bomb is access to a jail-broken LLM. Even knowing exactly how to make a bomb, a country-state will struggle to build one for the first time because it's a hard engineering problem.
They make great models, but the sanctimony and paternalism is getting old real fast and I will gladly ditch them in the future when the model playing field has (hopefully) mostly equalized.
Just use insulin pens or even just vials + syringes to manage your BG? I'm T1D as well with a 5.7 a1c. You don't "need" a pump and in some ways pumps make you ignorant of your own disease, like people who "need" GPS to navigate their own towns.
Seems like an effective DoS attack - ground all planes in the US by sneaking cheap bluetooth speakers into people's luggage with provacative device names
Water is handled at the city level, not the federal level. If you have incompetent local leadership, this can happen. Incompetent local leaders can (and have!) bankrupted their cities.
I never said AI code should be "unreviewed". I'm saying that instead of pulling in axios or requests (as a contrived example) to make HTTP requests, just use AI to generate some vanilla JS/Python that has the exact subset of functionality you need. Your code has fewer dependencies, CVE surface area, etc, wins all around.
Assuming you disable CGO, yes, the binary is always self-contained. However, I want to clarify a few things.
The "self contained" part is only important in that it lets you use busybox or "from scratch" as your container runtime environment which has a very tiny cybersecurity surface area compared to, say, ubuntu or even alpine which has a bunch of system libraries your go binary isn't using, but which could still get flagged for having vulnerabilities.
Minimizing dependencies of the go binary is a separate, but equally important task that reduces the cybersecurity surface area of your go binary itself to just "the go standard library" instead of "go stdlib + a dozen github packages"
Whenever I am working with a NodeJS project I pity the fool who has to do SCA because the CVE surface area is enormous compared to go, which has a fairly batteries-included stdlib
"A little copying is better than a little dependency." - Go Proverbs [1]
Most complexity is unnecessary. Adding dependencies to your project exponentially increases your project's surface area, which in turn increases its regulatory/cybersecurity burden, especially if your software is a medical device, munition, etc. Why is Echo/Gin/Gorilla/etc better/more secure than vanilla Go's mux? Just anecdotal, but we use the Echo web framework for Go and it's caused nothing but headaches. It does magical XML parsing by default even though we don't deal with XML which gets us flagged in pen tests. Updating from v4 to v5 broke production for us because they made an undocumented server config change that makes all requests have a 30 second timeout. Meanwhile vanilla go has the ability to register routes and middlewares, so what value is Echo bringing to the table? Ditto for lots of other unnecessary dependencies. A lot of times we just need one little thing out of the whole package, and in those cases a little copying (or a little AI generation) is better than a little dependency.
A static go binary with minimal dependencies running in a busybox container has a tiny CVE footprint when run through grype/snyk, etc. Do the same for a NodeJS app with zillions of dependencies running in an ubuntu container and you'll spend all day triaging CVEs.
I'm not saying "roll your own crypto" but I am saying "axios-like packages don't make sense to use any more in a world where AI+vanilla accomplishes the same thing"
Honestly I hope agentic AI ushers in a new age of minimal-SBOM software. I myself am moving all of my projects towards nearly 100% vanilla where possible. For example, golang. Why use [insert web framework] when you can just use vanilla for 99% of web apps?
There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
That's like 90 minutes of exercise a day if you take zero rest days... Not happening for most people. I think even marathon training requires less than 90 minutes a day on average.
Better to just publish the protocols/APIs and let the community roll their own
Honestly, depending on the repo, I would pay a reasonable fee to get issues or PRs I open seen. No different than paying a fee to add a new game to Steam - raises the barrier to entry and prevents a lot of garbage from entering the fray.
Don't they inject malware/adware into your build artifacts?
We recently switched from Node.js + Mathjax for rendering latex to Goja (https://github.com/dop251/goja) + Mathjax, and surprisingly it worked really well. We did this because the app is already 99% golang, and this allows us to eliminate the remaining non-go pieces, greatly simplifying the SBOM. And yes, we tried go-latex, but it's not nearly as feature complete as Mathjax. Not to mention using goja + Mathjax adds 10MB to binary size while Node.js adds 200MB+
OP said "The next generation of developers will, for better or worse, grow up using AI assistance to write their code, but none of them will ever become a Zig contributor."
You rebutted with (paraphrasing) "no, you can't build compilers with LLMs because LLMs don't invent new things"
I used a lot of words to demonstrate that you can invent new things with LLMs, including compilers, as long as it's a human + LLM iterative loop and not an unsupervised LLM running in a vacuum.