Yes? I mean I’ve never gone looking for a tech solution by browsing GitHub repos. I would have already done research online, read documentation, etc and decided on the vector database and then gone to the GitHub repo (or probably just installed from my package manager or docker and never even seen the repo).
Things like good documentation, good performance, good DX, and an active user community would be the deciding factors for me. One repo having more stars than another wouldn’t even factor into it.
The JavaScript fanatics will downvote me for saying this, but I'll say this, "using a single JavaScript codebase on your client-side and server-side is like cooking food in your toilet, sooner or later, contamination is guaranteed" [1]
This isn't a Javascript problem, this is a React problem. You could theoretically rewrite React and RSC in any language and the outcome would be the same. Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript.
> Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript.
Yes.
And since Python does not natively run in the browser, that mistake never happens.
With JavaScript, the desire to have "backend and frontend in a single codebase" requires active resistance.
It's the same vulnerabilities because Next uses the vulnerable parts of React.
Your rational is quite poor as I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then? Look, many of us also strongly dislike JavaScript but generally that distaste is based on its actual shortcomings and failures, you don't have to invent new ones plenty already exist.
> I can write an isomorphic web app in C or Rust or Go and run parts in the browser, what then?
If you have a single codebase for Go-based code running in an untrusted browser (the "toilet") and a trusted backend (the "kitchen"), then the same contamination is highly likely.
- You need to decide package manager and everyone has their favorite one: npm, yarn, bun, pnpm ...
- You need to depend on npmjs.com for dependencies, which has an unusually high number of malicious packages compared to other dependency sources.
- You need to use some framework like Next.js, which itself is a cesspool of backward-incompatible changes, combined with outrageous security issues
If you use deno you can consume dependencies much more securely from arbitrary URLs, such as your own. You can also set permissions for the runtime, though that might not save you depending on the severity of exploits.
Arguably the safest approach is to embed all dependencies in your source, and vet all of them for each release. But I'm glad deno lets me choose which registry I use.
Bun also allows for this but it feels a bit more tacked-on and less like an early architectural decision based around security concerns.
It wouldn't. I was responding to your concerns about the TypeScript ecosystem more generally.
You avoid the RCE by recognizing that React—and more recently Vercel's—management is a bit of a tire fire, and you should choose better tools with more responsible maintainers.
Part of what bothers me about this situation is that React appears to be a view library, and to many people using it that is what it functions as... But it's now a framework which extends well beyond the browser and entails all kinds of security risks that aren't intuitive at a glance, at all. A lot of people using Next probably have no idea about the security implications of the framework or how React fits into them. It's a mess.
Here is my single way of deciding what your favorite language is.
It is not "I like to write code in this language" but "If I am handed down a production ready system, I would prefer it to be written in this language".
A lot of people won't say the same answer to the first and the second question.
I think those are two separate concerns.
Writing code and running a tech business are two different things. I personally love Ocaml and think it's an excellent language and very underrated. However, I (probably) wouldn't want a production-ready system written in it, because it has a weaker ecosystem of libraries and frameworks, and it's harder to hire experienced people who already know or are willing to learn the language.
Indeed.
And the latter, that is, taking over and maintaining code written by someone else, is the more common concern in day-to-day jobs. More likely that you will get to build and improve an existing system than create one from scratch.
This heavily depends on the particular era of the language and the particular coding practices of the team though.
For example, I'm happy to maintain Python codebases with type annotations and type checking enabled. Those without better have a pretty solid docstring culture and be willing to add progressive type checking. It doesn't so much matter what version of Python it is.
They're becoming the norm for newer systems written in Python though. So I don't think the language is enough information to go on. This heuristic simply biases against languages that have been around a long time because more of their code was written before practices evolved.
Yes, but ... this depends strongly on whether your task is to maintain that production system in its current state indefinitely, or to keep developing it and continuously integrate with new technologies under time constraints. If the former, the right answer would probably be COBOL. If the latter, this is where things get interesting.
COBOL is used for the longest continuously running systems, particularly in the financial industry, many of which have been in production since the 1960s - mainly on mainframes, but noawadays also increasingly in cloud environments. There's nothing that comes close to the level of reliability that these offer, with the next closest probably being Fortran, Ada and Erlang.
I found this article with some numbers [0], with the top one being that "95% of ATM swipes rely on COBOL code". If you just need to maintain something in production, and only occasionally update the business logic, without having to upgrade the architecture, COBOL is the way to go.
My old boss wrote COBOL code for a core finance process… in 1975, well before I was born. He retired in 2019, and that code is still there with a few mods and probably will remain for another decade.
In fairness, it’s pretty fundamental stuff. But… the company has been working on moving to some Oracle bs for 5-6 years.
I have written a tool to easily run the agents inside a container that mounts only the current directory.
reply