DanielHB

The new coal plants are not planned to run a full capacity (or at all) they are meant for backup in case of environmental disaster and geopolitics (war, sanctions, tariffs, etc). So the actual amount of coal being burned is still going down.

Although it is highly suspicious why they are building so much unused capacity, it is as if they expect something to happen soon.

I have seen some uncensored versions of existing open models made by 3rd parties, I wonder how they actually work and in what way are the outputs different.

China has been known to set up local industry, destroy competition through subsidies, jack up prices repeatedly. US does it all the time too with tech services (uber, airbnb, are the more notorious, but all big tech is doing it now), but China is better at capex which is why they seem to be winning this race.

The main difference is that the subsidies in China usually come from the gov, while in the US it comes from VC money or anti-competition practices from established big-tech companies.

If China were setting up international funds and institutions for training with participation from other countries I would be 100% on board. Other countries could provide funding and workforce too and have a say in how the models are trained and safe-guarded. I am not saying China should bear the burden of open-weight models alone.

Ideally there would be open weight models from multiple geopolitical areas. It is not that different from telecom really, you don't want the whole world to be dependent on a single provider from a single country on this kind of stuff.

The fear is not about the models open weights it is the erosion of training capability in other countries. Why train models when they do it for free? Until they don't of course, or they start doing what the US is doing right now by locking out some models to government only or internal market only.

What people should be afraid is the rug pull.

Good point, but it could easily happen from both sides. The harness can just be default-tuned to think longer and harder on problems, or have dark UI patterns so the user _chooses_ the more expensive option even though the less expensive is available.

It just feels your own harness tuning for more token use protects these companies from audits and litigation. I mean this is exactly what is going on with this new feature.

As soon as tokens stop being subsidized I would not trust any harness made by a company that also charges for the compute.

Right now the interests align, but as soon as more tokens -> more profit (instead of more revenue and more losses) the perverse incentives will be too big to avoid.

It seems inevitable that open source harnesses will win. These companies would do better to just open source their harnesses.

It is all about the destination now where it used to be about the journey and the destination.

You don't understand what the OP said, your brain can get a intrinsic reward from seeing users use your LLM work. But LLM remove all the little intrinsic rewards from coding elegant systems to get to the point where you see users using your work.

It is all about the destination now where it used to be about the journey and the destination.

You put it in a good way, I have been saying this for my partner that I don't fear my job is at risk. I fear I am going to hate my job soon.

I am coping a bit by still doing stuff by hand, especially stuff where prompting the LLM doesn't save that much time. And what I call "adding good taste" to LLM output where I move things around to structure them in a more human-understandable way (by hand usually).

As far as I understand co-routines help don't really help with memory shared across go-routines. They only help in the fact you need to manage spawning and joining threads, making it easier to do stuff in parallel. But they don't provide thread-safety.

edit: I suppose you don't get segfaults or buffer overflows and the sort in go for accessing memory in a parallel context, you get recoverable panics. But that is still not really thread safety in my opinion, it is memory safety.

isn't it the exact same as C in this regard? The pointer being on the stack or not depends how it was originally allocated.

It also varies heavily on the kind of static analysis tools you are using in conjunction with your compiler. Some "bad" things about the language are just fine if they can be caught by the static analysis you are using.

It is a major problem with most really old languages, JS is notoriously prone to this kind of "remove the bad bits" thinking when in actuality most of those complaints are non-issues if you run a linter.

I think LLMs actually greatly improve accessibility, they are great about finding bad patterns in code.

You can literally run a "open this codebase and improve accessibility where you can" and get mostly perfectly good changes. Models and harnesses can be tuned to prioritize it by default, but usually the developer only needs to nudge it a bit to get good accessibility.

For normal OSS the only competition between contributors was for attention of maintainers to review and accept patches.

In an open-source LLM model contributors would compete with each other for computing resources for model tweaks and changes. The alternative model is that the contributor pays for the compute, but that increases the bar really high for contributions.

I think the main problem in LLM models is that you can not make a PR to an open source project to tweak some training parameters, prove it is an improvement and merge it.

If you can not run the training yourself you can not contribute. So open source contribution model does not work. All examples you gave have a fairly low threshold of capital expenditure required to be a contributor (basically a laptop).

Even back in the 90s a person could get a standard, but powerful, PC to do these things. The one exception was 3d graphics which took quite some time to become affordable and even there it was a single one-time expenditure (a workstation) per contributor.

VSCode at least prompts you to trust the project folder before running anything, otherwise it will use a globally installed LSP.

LLM corporate slop is the new version big data reports that nobody reads.

I am sad this infected code documentation and PR descriptions. This kind of stuff used to exist in order keep managers/executives busy not to keep engineers busy...

Static memory safety is a spectrum and so is code quality.

how is that different from C?

Zig gives you far more memory and type safety than C and without a borrow checker and a complex generics system.

Zig also allows optional runtime checks (at the cost of runtime performance).

There is no better language between Rust and Zig because they have different tradeoffs that are better or worse in different scenarios. It is more like Rust vs C++ and Zig vs C.

Yeah this is what I meant, structs are obviously a huge step up in type-safety but the ways you can abuse or bypass the typesystem in C and Go means you still have to be super careful about the memory your code hold, receive or returns.

I think Go developers don't think this is much of a problem because most of them are working on microservices where data is not kept around for a long time (usually a single request). And of course Go makes it a lot easier to handle data-access parallelism. So the benefits of a powerful type system are somewhat diminished in this scenario.

I think it is one of the reasons why Go devs don't see much benefit in Rust, the borrow checker is just not that useful in the context of isolated requests.

The best thing React ever did to the JS ecosystem was hammer in on objects/maps/dicts being immutable. In modern JS it highly unnusual to see code modifying objects (except right after creating them) even though the language itself has no convenient means of representing that.

Yeah we had some corner case that still required eslint, although I don't remember what exactly. We also have prettier for a few file types not supported in biome.

Languages like C and Go are so weak in the type system that it barely feels better than fully dynamic languages.

In my (really large) typescript project we have like 6 static analysis tools running[1]. Steps to get the project running: install nodejs, install package manager, install dependencies, run project.

The main difference is that in the JS ecosystem it is all installed at the project level, you don't need anything globablly installed besides the runtime and package manager (and even the package manager can be auto-installed as well if you set it up that way).

[1]: eslint, biome, prettier, scass linter, graphql-codegen, tsc, tanstack-router codegen. That I remember, might be more (although codegen might not be considered static analysis, it is needed for static analysis).

Pattern matching machines seems more appropriate.

I don't think so, my experience is that most often falls into two scenarios:

1) The devs pushing for more complex solutions, covering obscure edge case scenarios, feature-creep, "future-architecturing" because they are more interesting to implement. Classic over-engineering problems.

2) The features the managers actually want are usually boring or annoying to implement and the devs just work around any big architectural problems caused by the feature delivery.

1 is 100% on the devs, 2 it varies wildly, the willingness to address architectural problems are often under pressure by time-delivery estimates from managers. But many devs (especially in companies with low morale) will often just work around issues because addressing the underlying problems can be very difficult and/or time consuming.

Meaning either the dev wants to do the right thing but doesn't have the time, or the dev doesn't care enough and just pushes the tech debt down to the future (when hopefully they will be at another job).

LLMs makes both problems significantly worse, although they are also often very helpful with the big restructurings mentioned in 2. The dev can still be lazy and the deadline can still be too tight even with that extra LLM help.

Lines of code are a liability, not an asset.

I have been saying this for years, I once had a heated argument about a small system of maybe 1000 lines of code that was technically superior and more scalable but was freaking 1000 lines of code to maintain compared to the quick and dirty 10 lines of code it was suppose to abstract and make generic (for future use of course).

That with also countless debates over insignificant features in frontend apps at the cost of extra code. Frontend code is very susceptible to this maintenance cost dilema.

Many developers are too focused on delivery value compared to maintenance cost. It is unfortunate that non-technical management can see value delivered, but not maintenance cost incurred. With LLM-assisted code this has become many times worse.

Executives are salivating at the prospect of AI being able to execute their plans instead of real humans. It is not even about human payroll cost, you can just tell that many higher up executives just complain about how hard it is to steer the ship and get people to work on the right things.

Unfortunately they also don't realize just how much decision-making real people do lower down the org-chart. Critical decisions are often done by the leaf nodes, often without even discussing it internally with the leaf-node team. AI will likely not be very good at this kind of decision making or realize any decision needs to be made at all.

My company recently got a ton of AI credits on Linear and they are testing out this feature where whenever an issue is created in linear, it triggers an AI agent to automatically fix the issue. The idea is that when the dev gets to it, he will just check the preview-URL or run unit tests and rubber-stamp the PR.

It is unlikely this kind of agentic workflow will ever get cheaper. Agents get stuck in doom-loops quite often, just burning tokens without any value. Especially by prompts created by people unfamiliar with the codebase.

And it is becoming increasingly obvious that better models just use more tokens (and take longer to execute on prompts). So this kind of human-out-of-the-loop workflows will be forced to use cheaper models and be time-gated in order to not waste tokens. And then they will also produce worse results than a manual change or a more powerful model...

If tokens get cheaper you just put a better model for this kind of problem and let it run for longer.

But what is more insane is that we are using a ton of cloud VM time on top of a ton of tokens just to save a few minutes from a developer doing the same on his machine...

I don't think my company will keep this system once the free credits run out once they realize how much it actually costs.

The main problem of mixing sql and orm together is that most orms don't provide a way to do raw queries in a type safe manner that plays well with non-raw-sql queries.