Consumers will be spoiled for choice between deeply mediocre options.

Besides, what's the point of adopting new technologies if it's not to increase the quality of life? If everyone just exists in service of the product development lifecycle, who and what are the products actually for?

There's an ocean of difference between e.g. preventing the model from routing to something at the firewall level and just updating the prompt (especially given models' historically poor understanding of negative prompts, relatively speaking).

    That's true. But if America is so bad, why are you still in it?

As someone with a passing interest in infosec and cryptography, I'm sceptical of the long-term viability of this kind of product; it only takes one person successfully extracting a signing key to undermine the entire project.

    [0] https://leica-camera.com/en-int/news/partnership-greater-trust-digital-photography-leica-and-content-authenticity-initiative

We're also in a place where a lot of the usage guidance around these tools is still nascent. People are cowboying a lot of stuff, even as larger companies start to organize AI policy/safety/responsible use working groups to try and policy around the shortfalls of the technology.

IMO: if this technology persists, and if we figure out a way to use it in a broadly safe way, the value proposition will probably trend down rather than up, at least on the code generation front.

As a research tool, it shows some promise, though I still find the ethics of the technology disgusting.

Many of us are either openly having our performance reviews tied to AI use, especially at larger enterprises. Whether that's measured by sheer token count or just "how many of your tasks are you using AI for these days" (combined with the implication that question carries at many orgs which are heavily invested in AI).

If you want to give it a fair shot, it does take some time to get used to, coming from something like Python or Ruby. I won't deny that. I've found that using LSP-assissted semantic syntax highlighting helps, for me, on the typographic front.

I don't think typographic design is a key consideration in most languages' designs, though, and I don't think it should be. The main thing I look for is consistent, relatively predictable rules around the syntax, as far as that layer of language choice goes.

    > So .clone() significantly reduces the mental overhead of using rust with a small performance impact? I'm intrigued :)

    > Maybe it's harder to reason about the lifetime semantics while also writing code, and works better as a second phase (the de-cloning).

    > The demand for AI is currently overwhelming. As in, can't build data centers and GPUs melting overwhelming, companies growing 3x in a month while already at multi-billion revenues.

    > The models get better and better, Chinese open source is falling further and further behind American companies

    > The productivity gains are, at this point, obvious

    > The best talent works (or wants to work) in America and get compensated obscene amounts, the most capital flows through America, this is still by far the best place to start a technology business in the world

    > I think American technology was on the decline for the past few years before LLMs, but for the foreseeable future as long as American companies control the talent flywheel I think the new world of tech is going to be much more American than before.

Out of the three big geographic players, the US and China are jockeying for "most performant" models (whatever that means) with two separate approaches; the EU is trying to develop models that work best within their privacy, human rights and labour rights frameworks and laws.

All of these have have merits, though arguably the US's (de-facto) strategy of market dominance at any cost with as few restraints as possible will be the worst for society at large. The prudent thing to do would be to first determine if this is something that will actually live up to the hype (which IMO is still very much in the air), and then if it does, turns this into an international collaboration rather than a competitive enterprise.

It's not lost on me that this is a terminally naive point of view.

I come from a heavily Python background, professionally. I spent the entire first decade-and-change of my career using almost exclusively Python; I know it about as well as a person reasonably can (outside of scientific and ML Python, which I just never got interested in, but that's beside the point).

A year and a half ago I got a job doing Rust. At a surface level, it's about as far as you can get from Python in terms of ease of readability, but after 18 months I'm really reconsidering some of my points of view on the matter.

"Explicit is better than implicit," for example, is something I still strongly agree with, but my definition of "explicit" has shifted a lot in the past year. Seeing which guarantees are provided through mandatory, explicit, strong typing saves a lot of time over tracking down guarantees in MRs while reviewing Python code. If I see a signature as an `Arc`, for example, I immediately know that:

- It's thread-safe and memory-managed using reference counting (because `Arc` provides those guarantees);

- It's a type-erased object but is guaranteed to provide all the functionality from the `AudioInterface` trait (which, let's say, could be a supertrait of `AudioInput` and `AudioOutput` -- so it provides both of those);

- It uses runtime dispatching (since it's a `dyn` rather than a generic/`impl T` where `T: AudioInterface`)

I can choose to operate on it by reference with all the caveats that entails, or decide to either `Copy` or `Clone` it, depending on whether that's available for that type and if I can stomach the runtime cost.

All that to say -- Rust doesn't suck to review, relative to Python, in the long run. At first, yes, holy crap, it's such a huge cliff, and I can appreciate your point of view... but there's something to be said about having all this information surfaced as part of the language's syntax and semantics.

Python still has a special place in my heart, and I'd still use it over anything else if Rust isn't an option, but to echo a popular sentiment from other people who've made this migration, I don't know if I can go back to handwaving away whether or not something'll cause an allocation :)

Human languages are mostly very bad at this, and in particular bad at mapping low-level abstraction to the human written word unambiguously in a way that is as expressive as programming languages.

Inference closes that specific gap significantly (which is why anyone at all sees LLMs as a useful option to explore), but it will never be as good as a purpose-built language designed to map to a reasonable corresponding assembly language implementation.