hresvelgr
For what it's worth, it does look rather nice, and it looks as though care has been taken to construct it. Though next to existing solutions with more pedigree, it's hard to argue in its favour.
It is not, and for the same reason it's not over for mathematics. For anyone doing anything truly novel, and yes there are still software engineers out there doing that, it's still inept.
It's de jour to leverage formal verification as LLMs are quite good at looping it, but that's still a tool we had to invent to solve problems. It'll be truly over when we're being outpaced in the realm of invention but I have seen absolutely nothing to suggest that has meaningfully occurred at all. Coding by hand is not gone, there's just less of a reason to do so now.
Sure, but this doesn't exculpate them entirely. Adobe is where it is entirely because not enough people said 'no' as everything progressively got worse. If you find yourself thinking "well, I'm not going to risk my job just to go against my boss" then you're a small part of the problem, and I think those on the receiving end will understandably feel a bit shitty about you. You may not be an evil person, and in all other areas of life you may be a stand up citizen, but there needs to be some acceptance of responsibility. The road to hell is paved by those who look the other way.
Where I understand Jev to be a significant jump is that afaik the confidence scoring is actually derived from the normalised probabilities, and not a continuation in a chain of prediction masquerading as "confidence."
This is not a snipe, please go outside. Take some deep breaths, be around some flora, and fauna. This kind of cynical non-sequitur tells me you're looking for something to be frustrated at.
On the other hand, if you're working in an industry where you and your coworkers are developing novel solutions that aren't widely known, chances are you'll still be doing that by hand with some light LLM automation. There are industries with a lot of gatekept secrets where LLMs will be less useful. What I will say on that matter is this: if you weren't surprised frontier labs stole copyrighted work for training data, you'd do well to mind what you push through their systems.
I attempted many projects at a young age that I was absolutely not equipped for. The result of the attempts more often than not left me equipped, every time it left me better off. This is terrible advice.
edit: grammar
Zig does help you. Array slices, explicit nullability of pointers, defer errdefer, explicit allocators, built-in leak detection, bounds checks, overflow detection, the list goes on. If you need to play around on that side of the fence, Zig gives you a lot to make sure you don't mess it up. If we were talking about C I'd give you your flowers, but we're not. The most common issues and vulnerabilities that crop in C from manually managing memory are strongly mitigated by a quarter of that list.
Who are these "people" you speak of? It's possible to write software in low level languages that don't have these problems. Not a "non-zero" it might be possible, it can be done thoughtfully, and the popular notion it can't be done is backed only by incomplete anecdotes.
Should everything be written in low-level languages? No, that would be absurd. Is it a simple fact of life that not every person/team/organisation is capable of meeting certain standards of rigour? Yes. That's not to say anyone in the Bun team could not become sufficiently competent in the future. For whatever reason, current experience, incentives, and personal motivations did not make for a conducive environment to make Bun watertight in Zig.
That's just it, using Zig required more rigorous engineering than the Bun team were capable of.
"Her optimism was load-bearing,"
versus:
"Her optimism was enduring."
Exactly the same meaning and connotation. It stands to reason that the terms with the most semantic flexibility will have preference across all contexts. So in response to:
> maybe we should be learning from Claude rather than complaining.
I'd say let's not steer ourselves into regular language and keep some vivacity in our expressions.
> In C you have loops, functions structs. All things that make no sense in assembly.
One can reasonably infer that a loop will roughly translate to some type of conditional jump instruction. Function structs are just pointers and call instructions. The former point was that there is little runtime getting in the way of how the constructs could be expressed, and a long time ago it may have been the truth, but not for modern compilers.
Anyone with sufficiently good taste in how to program effectively and architect will disagree with you on this. The short leash method is how you ensure good results when you're functioning outside of the training data. If you're even a modestly above average programmer this is afaik the only way to ensure fast, quality development with LLMs.
> This again feels outdated. I think we're mving towards humans no longer needing to understand a codebase, and letting AI drive it.
I think you are perhaps unaware of a world of programming where AI is still woefully inept. I have observed very consistently in all languages with manual memory management frequent issues with handling it. Trust me, it's not as simple as sticking it in a loop with Valgrind.
There are good reasons for this (supply chain attacks, dependency hell), and while Odin doesn't have a package manager it does have a concept of a package. There is nothing stopping anyone from downloading and adding them to a project, in fact Odin developers do this already. The Odin core library is absolutely massive and contains a lot of what you would need for most projects, vendor rounds it out. The purpose is to be batteries included so your project doesn't have to rely on as many dependencies.
> I think zig is also highly opinionated but it always seemed to me that Andrew started from solid pillars
It's funny you say that, because I hold the same stance for how Odin was constructed, and the examples listed hold for Odin too. There is a lot about Odin's design that is consistent with Zig. Check it out, you might be surprised ;)
> Odin on the other hand is just some developer's personal taste marketed as "Programming Done Right". So, if you disagree with any choice Bill made, you're not doing programming right.
What do you think every programming language is trying to do? Solve the issues of the author. Bill has strong opinions about programming, so he made a language and a reasonably successful one at that. Given the swathe of people who would just complain, it's refreshing when people try to instead better the world relative to their values. Say what you will, he does it because he cares.