Unfortunately, it's impossible for us to verify what parts of the demo are 'realistic'. Did they use assisting technologies (e.g. a wire rig)? Is anything repeatable, or are the components one-and-done?
The software industry has taught me how sneaky a demo can be ;). That's without considering Tesla's history of bonkers claims and sus demos (anyone else remember the bulletproof windows?).
Edit: Removed a rhetorical question about the demo. Apparently there was a live audience, so they couldn't have just made a very tiny Roadster haha.
I'd really like to understand how you think a wire rig could support the flipping in mid air and stuff; that would be some great engineering. How do you imagine that would work?
I wouldn't say the bulletproof window demo was "sus" - that was just a Windows-crashing-during-the-demo screwup. They didn't fake the stress test on stage :)
That actually would be significantly better, because then you could work out under what conditions they were wrong and correct for it. But being stochastically wrong means you have to check everything, because you never know when the errors will creep in.
If it were deterministic but chaotic, which AFAIK is the case for LLMs running at temperature 0, then you would have to likewise check every time you changed anything and couldn't meaningfully correct for it.
> I mainly write code that cannot fail. And if something does go wrong, I must handle that in an appropriate way. Asserts are never the way because they terminate the program.
If your code which "cannot fail" actually fails, terminating the program seems entirely reasonable. All logic could be wrong at that point, and it's better to crash loudly and fix the issue than to try to limp along with logic that probably won't work.
A single binary accomplishes most of those things just fine. Only thing it doesn't get you is isolation, but you can isolate things if you want even then (for example, FreeBSD jails are dead easy to set up).
ok, so you're just using a container with a different name? You can put the single binary in a container and call it a jail if it makes you feel better.
Well yes, but that's the point entirely - you can easily put a binary into a docker container, or a jail, or on a VM. But when something is shipped as 5 different docker containers it is MUCH harder to extract it into something you can run without docker or in a different configuration (like sharing a postgres instance between multiple applications).
One distribution method is flexible and can be deployed however you want, the other prescribes solutions and makes any customization difficult.
I'm confused. The original post said "why docker compose? a single binary dominates any docker compose", (I assumed dominates here means wins over because it wouldn't make sense otherwise?) someone replied giving the additional benefit of containerization, then someone replied to that saying you get all those benefit from single binaries, and if you want the system isolation you can use a freebsd jail, which is like saying "if you want the benefit of containers you can use containers"
Most applications do ship in a single container. whether it's a single binary inside, or a bunch of python or js files or shell scripts is a separate issue. If there is a dockerfile then you know how to build the container. a single binary is easier to build the container for yourself, assuming you also know the binary dependencies of that single binary. Like maybe ffmpeg or yt-dl cli on the path?
Applications that ship as a list of containers are a completely different problem. Those applications are either a victim of their own success, or have developers that come from a particular background.
I've never felt hindered by docker. It's pretty flexible. If I need even more flexibility I'm reaching for k8s, where I am still containerizing any single go binaries
Are you saying it's hard to edit a docker compose file? Being one service or 5 doesn't really make things more complex. I often point servers at my own postgres container instead of spinning up an extra one (so just remove that from the compose for example). That's kind of the entire point of compose, it's so flexible.
It is bizarre having conversations with some people. There is a reverse engineering framework that had God of War 3 remaster running natively on Linux at 120 fps and all this tech is AI-assisted. A friend of mine was demonstrating it running to me last night, and then people like yourself tell me AI can't do anything when you can download and run it yourself.
I just had it write a bunch of script hooks for gamemoderun and at work I had it do probably a week's worth of work in an afternoon earlier today. It also smoke-tested everything for me.
It is utterly bizarre, and I think you are just denying reality.
> Someone who acts like a radical on practical issues will almost certainly act like a radical in other areas as well - including areas that matter to me.
Not using LLMs is a practical choice. The tech doesn't work, and if you let it run amok in your software, your software becomes crap. I try to avoid projects that use LLMs for development as much as I can, because those projects have a much higher likelihood of being a buggy mess.
Unfortunately it is. Thought the whole thing was a scam until six months ago. I think pretty highly of my development skills and have to be objective and admit I am outclassed in debugging and operational tasks now (and it isn't close). Writing non-script code isn't quite there yet (they are bad at abstraction) but I can't confidently predict how much longer that will be the case.
I know a few very serious and well compensated programmers with decades of experience. These people work on prominent open source projects, climate modelling, linear programming, large org enginneering. Every single one of them uses LLMs heavily and swears by the increased productivity of using them.
Maybe that's true, I don't know. I make no claims of an unbiased sample. Merely a counterfactual to the parent comment's claim that they aren't useful.
> for an engineer who knows what he's doing, LLMs are of very limited use
LLMs are very good at code analysis, and finding both security issues and optimization opportunities. Yes, even in code written by highly experienced human engineers. Failing to have an LLM look for places where your code could be optimized is, IMHO, indefensible. It's like shipping your binaries compiled at -O0 - deliberately choosing to waste your users' time and hardware resources because you couldn't be bothered to properly configure and run a tool.
Code has never been the bottleneck for a skilled engineer, and if you value high quality then you need to spend a lot of time reading over the slop LLMs produce to turn it into something hardened and reliable. So, for a skilled engineer, LLMs have a very marginal benefit in terms of delivery speed.
I think there is some nuance to this. As a self-identified skilled engineer, most or what i -actually do- is not bottlenecked by writing code. However, there is a lot of stuff that I pre-LLM -didn’t do- because it was medium value and high effort. There is a class of work that is now zero effort to have an LLM generate, still medium value, and crucially low effort to validate.
I’m not sure this is a large class of work created in the long run, but since this efficiency is new, our backlogs are full of these tasks, and people are feeling immense efficiency gains from unlocking them.
They literally just shipped a massive update for a game they've been developing for several years (Deadlock) and are releasing more content for it this Friday
Do you think Deadlock will not devolve into a mixture of gambling and hvh like every Valve multiplayer game that’s been relevant in the last 10 years (except Dota because hvh in dota sounds complex, so it's just gambling there)?
Fortnite avoids this by having no gambling and by making hvh infeasible FYI
I have only very rarely in my career encountered code worse than what an LLM produces. It happens, but your typical programmer is still quite a bit better than an LLM.
> People still talk about "Vibe coding" or implying "vibe coded" stuff is poor quality
Yes they do. Because it is. Anyone who cares about the quality of their product is, at minimum, carefully reviewing the output from an LLM to make sure it didn't sneak in anything crazy. More likely they are writing a lot of code by hand, because that is faster than reviewing and correcting the LLM code. Competent developers do not just hand it off and say "the AI is really good so I can trust what it put out".
reply