I dunno,unlike the crypto/NFT era, Rust rewrites have demonstrated measured performance and memory savings gains. Some grimace when they see "written in Rust" as a tagline but my immediate thought tends to land more on the "thank God this isn't an electron app" side of things
Operative word is “fanboys”, I have mostly no qualms of actual rewrites to that language. It’s the fanboys who insist upon injecting themselves and their opinions everywhere with net negative impact.
You're comparing the rust rewrite of a web-based desktop application with the rust rewrite of a compiler+interpreter/jit. The former improves things by removing 12 layers of abstraction and an entire browser engine. The latter, not so much, it's already bare-metal.
So as much as people on this forum love to shit on it, PHP is already very fast and memory efficient.
The gains from the ongoing rust rewrite are (in order):
Earlier this month I ordered some PCBs. Due to the tariffs OSH park was actually a viable competitor for small batch runs. I've also found them to be higher quality than PCB way
Downside to this: it takes a long time, I have to source the parts myself, and I can't separate design or programming errors from soldering errors. (There will be many of those) I have not figured out a system to So: Having JLC do the assembly is a no-brainer for the projects I've done.
Agree with this. I used to do my own assembly almost as a point of pride, but the Chinese shops will do it so cheap now that you are really just torturing yourself to no purpose. (It’s fun the first few times, but gets old pretty quick.)
A surprising amount of tracking and diffing in legal texts is actually very different to git. It's a trap to assume software version control fits the needs for legal work.
Let's say you have some case law, and to know if it's relevant you need to pull the primary law/codes and regulations .You also need to know when the correct versions of everything are, so the case law needs to resolve to the correct version of the correct piece of legislation. "What is an atomic unit of legislation?" is also fuzzy as amendments will both move and edit named blocks of legislation at once. It's a big messy very hard to track pile of moving targets, and you need to account for the temporal aspect while linking documents not only to the changes but also to documents at certain revisions. Standard git and other version control has trouble expressing many of these concepts, and while it could be hacked in, I have found it more effective to create a purpose-built tool for the job.
A lot of folks have been praising the harmony of Claude code + nixOS. For those of you doing this, I would recommend you to ask your agent to switch your config to nix flakes. It's a much better paradigm for working with the versioning than the default channels interface. Additionally, you should ask your agent to look into home manager, if it hasn't done so already.
It's also decreased the friction of finding software that hasn't been given a package for Nix yet but can't run on it.
I just go into the directory with the software and tell Claude Code to make me a Nix shell or a Nix flake that can run the software. Then usually within a couple minutes it'll work out what it needs to run and build it.
I recently did the same thing with ComfyUI which I was running through Conda. I had Claude code go through and figure out how to make it run just in a plain nix shell with a venv. (I always struggled getting it to recognize my NVIDIA GPU without Conda)
I feel you're missing the point. AI has no impact on recreational programming, it's about satisfying your personal curiousities and interests. I'm currently hand rolling a database project in rust because I find writing rust is fun. If you're pausing to ask yourself "what's the use if you can just use AI" then you may not have liked programming intrinsically to begin with, but instead the second order effects it gave you.
It somewhat does have an impact on it, because a cool part of recreational programming for SOME people is to share their hobby with others, but the value that others will place on that sharing is diminishing with AI. It's just human nature to value something less or find it less impressive when it can easily be made with a machine.
This is how I feel, I like to share the cool thing I did and be part of creative spaces with other people, but I feel those spaces have gotten smaller, or changed.
The internet is increasingly full of the types of people it's pointless sharing anything nascent with anyway. I'm sure a local meetup will see your side project very differently than a subreddit or hacker news (the latter will even send armies of bots to take you down).
It seems to me that you are still doing it to showcase it to others. I understand it feels great to talk about it with people understanding the effort you put in, but it really is a personal thing IMO.
It's weird to think of these kinds of models as having "output tokens". Cross-encoder approaches like Laya add a [MASK] marker per option, but nothing is generated the way an autoregressive transformer generates. It's one bidirectional pass over your input, then a small head scores each option, so you wouldn't really pay for output as much as only input
Yes. JEV generalizes better because they probably have an enormous corpus and trained on it for a long time. Laya's out of the box model is much weaker. However, in the age of LLM's it's incredibly easy and cheap to generate large datasets to fine tune laya for your task, and the training loop is pretty quick and cheap too.
It's so easy that I question why I would ever pay for JEV when eventually I'll have done enough random things that I will also have a large corpus and likely a general model as well.
Isn't the point of Jev that it generalises better?
It's a fast classifier you can use out-the-box, ~1.5bn tokens is about $40 (I've been hammering it)
It just works ... a whole bunch of low-level/low-importance workflow stuff that was getting farmed out to small/fast LLM models now has a competitive alternative ... and bits that hadn't even been considered to go into some external descision/classifier service can be tested/deployed at ~$0.00003/req
I don't get this wall of negativity on it, it's genuinely innovative/useful tech ... would expect HN to be more positive, regardless of whether it's the absolute best execution
It really does just work. And it works so well I already integrated it into my product. Saves me about 75% of costs for the section its working in, which isn't a small amount. I see a lot of negativity and I don't really get it either. Its so cheap and so fast, why not give it a try?
I think your point is valid but many are annoyed that it is presented as groundbreaking, revolutionary, novel frontier tech when it is a known classification system. It’s the hype that feels undeserved. Honestly it was one of the best marketing campaigns I’ve seen.
I didn't see any negativity in the post you replied to.
I think the point being made is that Jev is great but it has no competitive moat, and open source versions will very soon catch up if their secret sauce is just synthetic data.
You should try building something with it, the hype is what it is, but the model is crazy useful.
I'm building a woodworking app and I've managed to create an autopilot that can take a simple instruction ("get me 5 2x4s", "cut the middle 2x4 into 4 equal pieces", "move the 2x4 3 feet left") and the action instantly happens with next to no lag. There is already an llm but now it can share an intent, and the geometry system shows jev the various actions and jev chooses the action that gets it closer to the goal until it has found a state that matches the intent or gives up. The result is the llm can think "higher level" and let the cheap fast model grind out the options in a relative blink of the eye, without the 30s of reasoning the llm would have done about the various operations it could try.
You're correct that writing code by hand has been heavily displaced by AI programming, but understanding how things work isn't really an "antiquated hobby" and this mentality causes a lot of people to incorrectly assume that latent knowledge of how to program is no longer useful.
It's still pretty undisputed that if you know how to write code, you can generate better AI code than someone who doesn't, and do it with less tokens. I think it's more like in university where in other engineering disciplines you learn the math and underlying concepts and are forced to do them by hand. This gives you an understanding of what you're doing, but in the real world you, ya know, just plug that stuff into matlab.
There is some sense of rose-tinted glasses of pre-LLM coding. A lot of human written code, particularly at the enterprise level, was of low quality well before AI automated it.
So much "bad" enterprise code evolved into that state over years or even decades of small changes. Meanwhile, last year I got to watch an LLM-authored codebase speedrun itself into a similar state in only a couple months. And I would say that the enterprise code was actually better. It at least did its job fairly reliably. The LLM codebase was riddled with defects, so much so that it ate up all our time and our feature delivery rate ground to a halt.
There are two observations that really eat at me:
1. Studies seem to indicate that agentic coding uses 2-10x as many lines of code to accomplish the same task.
2. One of the only really well-established empirical results in software engineering is the strong association between LOC and defect rate.
This is happening all over the place right now. There is a ton of greenfield happening, which further adds to the illusion of speed. Eventually you produce a big old pile of shit that even with the help of the LLM is weird to reason about, and it slows way down. Many such cases.
Writing code at enterprise level is insanely difficult. You are constrained by budget, staff, legacy databases/environments, business rules hiding all over the place, and people.
You can't just rewrite everything. So over many years people are touching small parts of the pie.
Yeah, enterprise code has that trope of being enterprise-y, verbose and bad. In my experience, that has always been the opposite. At the big corps/FAANGs I worked at, a single line of change can adversely impact millions of paying customers, so a lot of the verbosity and harnesses exists to dampen the failure modes.
Most of the terribly written stuff has always been at startups, where devs fling nearly anything across the finish line, if it barely works the happy path.
I don't doubt that. But humans still need to be responsible for understanding what they're shipping. And IMO you get your best understanding by actually writing some code. Even if you don't actually ship what you wrote.
Let’s not romanticize it too much... A lot of enterprise systems are built by developers copying an old AbstractBeanFactoryFactory from a 2011 stack overflow thread without really understanding it :)
Nobody is. It's the AI slop which is supposed to replace this shit which barely worked with equally shit shit which doesnt work which people are romanticizing.
Most of the human written code was slop, but the really fundamental and successful stuff we relied upon and which we didnt want to throw away? yeah, not so much. most of that was actually really good.
those EJB monstrosities were routinely swapped out by some saas written in python by somebody who did it properly and werent responsible for a lot of late and over budget projects which barely worked or didnt work.
> But humans still need to be responsible for understanding what they're shipping
I don't necessarily disagree. That said...
Why?
I've been grappling with this myself. There is an easy/obvious answer, but I wonder how stable/permanent it is. If you feel strongly about this, are you willing to unpack your judgement?
Yeah... like we all get to start green field projects and write all the code we should understand. Many of us cut our teeth on bad legacy stuff with no proper documentation made by "engineers" long gone. At least a LLM can easily make sense of this mess.
Indeed. And not fair comparisons ”look at the quality of this small one-shot Claude hobby project. The quality is less than this major open source project written by some of the best developers in the world”
To be fair the pitch has frequently been that Devin/Claude/Astra/whatever is some sort of superhuman bottled John Carmack that will single-handedly replace entire teams of developers.
Yea, that extreme side exists too. Truth is inbetween. AI with the instructions from a dev that knows what it is doing writes better code than most regular 9-17 devs.
1. People didn’t wear that as a badge of honour though.
2. A lot of it wasn’t. Low quality code/speed serves a purpose for point solutions and scripts etc. That’s not the same thing as writing a core system and if the user doesn’t put any credentials in for an S3 bucket then it falls back to giving information about your own S3 bucket (as I’ve seen just this week).
3. Plenty of companies you can discern the difference between mission critical systems versus “business” systems where if it falls over it’s annoying but not the end of the world.
This was always due to pressures by management and the company environment, not the workers themselves. It's hard to blame the people writing code when they have to deal with nontechnical leadership that wants to have a feature factory or never given appropriate resources to solve problems.
Blaming workers is always an excuse by poor management.
The pressures from management and the company environment are not always a bad thing. It really depends on whether the pressures are coming from a logical business perspective or whether they are just coming from stupidity or ignorance. In a business environment, taking a long time to ship great code can mean that the company goes out of business, and then the software developers have a lot of great code and no income.
Wait. I didn't say anything about making people miserable. And I'm not talking about some weird kind of pressure like yelling at people.
I just mean the normal, almost inevitable kind of pressure that comes from the business situation. Management has to somehow figure out strategies to handle the pressure and it has to communicate these strategies and the reasoning for them to the engineers in a constructive way.
Generally, this is the pressure to be competitive and make money. It does the developers no good if they spend so much time writing great code that the company goes out of business.
Nah, you're still blaming workers and not leadership. If leadership is okay with not training workers (something American corporations would do in the distant past) then it's not fair to continue to blame workers when leadership is clearly aware of the problem and would rather pocket the money than help workers.
These companies pay management more than workers for a reason, if you can't even admit that they are to blame then what are you trying to do here? Just attack workers for what reason exactly? Being anti-worker is a great tell to never trust a person.
We're talking about professionals here. People who (at least in the US) often make several multiples of the median worker. Competence is assumed, and every company I've been at has had programs to pay for additional school if the employee wants it. IIRC at least one had an explicit book allowance, and I don't doubt that I could expense books right now if I asked. Do surgeons and lawyers complain so regularly that management doesn't train them? Or are software engineers just this desperate to be seen as "not a real professional"?
Who even is supposed to be training us? We're supposed to be the experts. Unless you mean mentorship, which is also generally already a thing at any company that has more than a handful of engineers.
There is no professional developer in the US. There are no licensing requirements to write code. There are no repercussions against developers that write code that immiserate or kill Americans. The person slinging wordpress plugins at an agency is equivalent to the person writing malware at Meta in the eyes of the government.
No one is training us because there are no regulations in our industry. Sorry but I still reject the premise of the other poster.
Also yes, in other industries professionals do complain when they aren't given their mandated time to learn while working on the job.
We are given time though. Maybe not at some small sweatshop? But at least at big companies all the jobs are salaried, and either no one cares how exactly you spend your time, or they explicitly say it's fine to spend some time learning, and will pay for materials or courses.
They're generally not going to teach you how to program or what the latest technologies are or what the best ways to do things are because that's literally what they're paying you for. But IME they definitely give you plenty of time and autonomy to be learning things at work.
I do blame management for letting these people through the interview process and then not firing them. But that’s independent of the fact they exist.
Training doesn’t solve every problem, the worst programmer I ever worked with that a PHD in computer science. Everything he made was horribly slow, wildlife overly complicated, and buggy. Worse he wouldn’t listen to anyone correcting his issues. He’d store numbers in the database as strings to be database agnostic etc.
Let me throw a curve ball at you: do you accept the premise that most modern corporations are centrally planned economies under the rulership of monarchies, oligarchies, or general authoritarians? If so, do you think introducing democracy into the workplace would help alleviate issues you care about?
You do not like bad workers, management doesn't care. They pay bad workers the same as you, bad workers can get promotions the same as you, you will also get laid off with the bad workers as well; or maybe even worse, the bad workers get promoted into management themselves. How do you want things to change in such an environment?
You have no authority to do anything meaningful as a single worker, what if you were given a voice to actually make these claims and have other workers decide what to do based on your voice?
Workplace democracy seems like an interesting concept to explore if you truly want to create better environments with beneficial outcomes to all, not just the few:
> do you accept the premise that most modern corporations are centrally planned economies under the rulership of monarchies, oligarchies, or general authoritarians?
No stock owners are ultimately in control of public companies. That doesn’t fit any of the models you just described.
Similarly companies are not independent of government control which inherently separates them from management systems associated with governments. A CEO is limited by the law in ways that a dictator isn’t.
I've only worked at companies with great leadership. This is in the Nordics with very strong worker protection. And yet most of my colleagues including myself have been pretty terrible and write dirty code. It's not a management issue and it's not anti-worker to acknowledge this fact.
Your great leadership doesn't seem to care, so either your management knows better than you or maybe you should push back on the notion that you worked with "great leadership."
Only poor leaders ignore their workers, which is what you seemed to have actually experience.
I would argue the average code quality of LLM's today is much higher than pre-AI code quality. It's better documented, more readable, and has fewer bugs. There was a brief period where frontier models were still worse than the average developer, but that period among frontier models is well past us.
Are you saying that pure vibe coding by a non-technical person produces better code than pre-LLM developers, or that experienced dev + AI produces better code?
Both of those things are very different, and AI shouldn't be the one taking the credit if it's the second case.
I've been doing development, in one way or another, since the 90s. I've worked with dozens of teams from enterprises to startups. Hundreds of developers. The quality of work has been all over the place, but the majority was not great.
I'm arguing that what people today call "AI slop" is already higher quality than what most developers created historically, and the fact that tests and documentation pretty much come for free now means that the floor has been raised.
The quality of AI generated code is not great. Yes, it will get better. It's already better than 65%+ of what regular devs can do AND it is faster to produce, iterate, and release.
This is off-topic, but I strongly dislike AI written documentation.
When I see AI house style my eyes glaze over. Just this morning I reviewed an RFC from a colleague that he said was a spec for a web service. The document had no introduction, no context, it described endpoints for 2 distinctly different services instead of 1, and made no effort to reconcile why there are 2. It was scattershot with details, some of them important, some completely irrelevant. It was replete with typical LLM-ism.
Basically, it was a dump of a conversation he had with an LLM. As a document to build shared knowledge, it was nearly useless. The only feedback I could provide was a polite "I do not understand what you are trying to build".
But, supposedly, another engineer is already working on implementing this spec. I assume the other engineer just cycled this "spec" into his LLM, and off the two of them went. \o/
They are trying to pull me into their project right now, I stood up some containerization infra for them. But, oh boy, do I not want to join. I looked over their codebase, by LOC the codebase is 35% comments, and a lot of the comments are contradictory, there are dependencies that are not used, there is no tooling of any kind (no type checking, no linting, no PR process), there is no auth (this code is already running in production lol -- they have public endpoints exposed that can be used to scrape/mutate internal company data). Another 30-40% of the codebase is unit tests that test trivial stuff like whether their framework's serializers and ORM work, ex: x=DB.create_x(arg=1), assert(x.arg == 1).
At the intuitive level, I do not understand people who say coding is solved... To me it seems like LLMs are a multiplier (LLMs are amazing, sci-fi level shit), but if you multiply a negative number or 0, you get something that is <=0. Making agentic coding work requires a lot of discipline & expertise.
Oh man, the "unit tests" that test whether the framework/browser/language is doing what it's supposed to drive me insane. Those have their own tests already! Test the unit under test, that's why it's called that!
AI documentation is practically worthless ime. I forbid it in my projects. It's almost always more useful to not have any documentation and read the code than to rely on AI docs.
reply