Well that's what I said before, that I don't touch code anyway. Which means you go with the language that works best with the AI.
In my experience, that's Rust. Or maybe Haskell. The more guardrails the AI has, the better.
I bought a Ford F-150 XLT (the full-hybrid pickup) and was very disappointed to find that several of the features (Including Blue Cruise and navigation) were subscription-based with an initial free period of a year or so.
Other than that the vehicle is fantastic - but was very pricey when I bought it, so having to pay over and over for the features was a very annoying surprise. (They quit working rather than quit updating when the subscriptions run out.)
... a bunch of cancer progression theories based on cell culture progression had to be thrown out when it was discovered that the cultures were being contaminated by a particularly robust and aggressive cancer cell culture, HeLa, which had contaminated lab equipment like environmental chambers or survived equipment sterilization and eventually took over culture lines in labs.
If it's an SSD it's not necessarily "incredibly slow" if you're just playing around and aren't ready to spend fifty thousand dollars on your chatbot
Ok, but some of us actually want to do something useful instead of just try to win the trophy of making a model run on the cheapest hardware. Unless you're generating at least ~30 tokens / second, it's not useful.
There are only 6 billion internet-connected people in the world. They invested $2.5 trillion. Just to make the investment back, they need everyone to pay roughly $400 each.
If you want to split the cost evenly, sure. But a team of 3 people working at a software company today typically pays the AI companies about $5,000-$10,000 a month, so I don't think they need to rely on the parts of the world where $400 is twice their income.
Who the fuck leases a PHONE.
I think that's the question we should be asking. Just buy the thing. If you can't afford to buy the thing, then get a loan/card to buy the thing.
And a phone just shouldn't be that expensive or difficult to maintain or break so often that you can't do either.
You can keep your vanity plate names and waste all the money you want on them.
Nobody cares any more. They just google or bookmark you.
Yeah, I mean, who would call a website slash dot, because it then becomes w w w dot slash dot dot org....
My latest project is a 16,000 line script done in Python. It was pretty big for one person.
16kloc is a small project.
I should soften what I said before: You can get away with seat-of-the-pants work if one or more of: (a) your projects are small, (b) your projects are non-critical or (c) you invest in massive testing and validation.
In my old job, if I made one kind of mistake it could prevent three billion Android devices from being able to boot. If I made a different kind, it could result in the same number of devices being insecure against data extraction and other attacks (of course, OEMs often made those mistakes for me). In my new job, if I make mistakes vehicles can crash and people can die.
I want all the help the tooling can give me, and I spend a fair amount of my time building additional tools to prevent mistakes. None of it eliminates the need for testing, of course, especially when lives are on the line, but bugs that get caught by the compiler cost almost nothing. Bugs that get caught by QA, or, far worse, in the field, are very expensive.
Note that there are big systems built in Python. Instagram has millions of lines of Python code. They also mandate explicit type declarations everywhere and they built their own static typechecker, Pyre. Lots of other people have built typechecking libraries and tools for Python, trying to fix that problem. Maybe the next time I write Python I should try some of those tools.
Though I probably won't ever write any Python again. I really only use it for quick and dirty scripts, and these days I tell AI to write those for me, and I don't even bother to read the code. If it works, fine. If it doesn't, I tell the LLM to figure out why, and fix it.
Is there any other kind?
Sure there are. Some bug reports, you look at them and dig in and say "Damn, that's obscure. It depends on subtly-wrong but arguably-correct-in-isolation mistakes in four different places. How the hell did they even find that?".
Granted that it's more common to glance at it and just be ashamed, or to look at it and say "Really? You think an attacker can do A, B, C, D, and E, all at the same time? Oh, and to do B or D they'd already have to have the system mostly compromised. Okay, I'll fix it, but no way in hell is that actually exploitable."
Yeah I don't need help from the tools.
Sorry, but you're wrong.
I think you're right.
I'm surprised they're projecting profitability as soon as 2030, actually. That's only 3.5 years away.
I would guess they are ignoring some expenses there as well.
Maybe... if the projections are in formal filings I don't think they can do that without risking SEC penalties. They can be optimistic about revenues or falling costs or things, because who can tell? But straight up ignoring things, probably not.
And it's not exactly an ad for US models when HuggingFace had to rely on a Chinese model to analyze their logs because the US model they tried refused to answer.
It is if the customer is the US military.
* US model is capable enough to hack its way out.
* China's model was able to detect it.
*
Nope. You misunderstood. It's not that the US model wasn't able to detect it, it's that the US model's guardrails prevented it from explaining. This doesn't demonstrate a capability gap against Chinese models, it demonstrates a two-sided failure of the safety protections of the US models. On the one side, the safety guardrails on the OpenAI model failed to prevent the attack. On the other side the guardrails on whatever US model(s) they tried blocked the model(s) from explaining the attack (presumably to protect against the explained-to people from learning how to perform it).
Nope. I didn't misunderstand. You may have misread what I said, or attributed the previous comment to me.
You said that this creates an arms race, which implies that it's a question of capability.
Marketing? Because companies famously want to use models in their networks that just run off and commit major crimes? *eyeroll*
To each their own. I'm a python guy. I don't like typed variables or specifying anything I don't have to. Lately I don't work with code at all. I have AI do it in Python first then port to C++. It would be interesting to see if I could port to rust.
I strongly dislike dynamically-typed languages like Python. They're okay for toy programs but for anything of any size... you'd better have one hell of a good test suite because the tools give you absolutely no help. I want strong, static typing. I want a very picky compiler that won't accept anything that isn't exactly correct. C++ is good. Rust is better. I do like type inference so I don't have to manually specify types very often. C++ is reasonably good at this. Rust is better.
I also do a fair amount of work on very tiny systems, programming on the bare metal. Something like Python is a complete non-starter there, it just won't fit. C is the norm for those cases, but C is almost as loosey-goosey as Python, but without any run-time checks. C++ is much better than C. Rust is better yet.
The worst non-hardware bug I've ever dealt with in nearly 40 years of professional programming was in Python, using the Twisted framework. I traced it down to one place that took a pure abstract interface, instantiated it, then called methods on it!. Even logging the type of the instantiated object showed that it was the abstract type. Someone way too clever had built a dependency injection framework that was so magical that there was absolutely no way to figure out what dependency was being injected.
I also have AI write most of my code these days, but that actually increases my desire for a very picky compiler, because AI does a lot better with those guardrails in place.
Neutrinos have bad breadth.
