You would need a significant sample size to make any sort of conclusion from such a probabilistic process. Then there's the issue of how you would actually grade/compare.
Small anecdote on the mobile/robotics part, two years ago I was tasked with a small research sensor/timelapse platform. I reached out for the Pi Zero 2 W, the new Pi camera, and the largest USB battery I could buy. Perhaps I had unrealistic expectations, but I was surprised how much power it draws, even at idle. The napkin math said about 6 days (0.5 W idle, 2 W loaded), in reality it was only 1-2 days.
In comparison, my older laptop idles at around 5 W, even with multiple applications open. Similar experience more recently when looking at setting up a small home lab, the new Pi 5 seems to idle at around 5 W. A friend told me he has an Intel-based mini PC that draws less power. I'm tempted to try re-purposing an old phone, that should in theory do better.
This is AC wall power as measured by a kill-a-watt, I have an Intel N150 mini PC here with 12GB of RAM, 512GB cheap NVME SSD, with wifi active, it's 8.2W idle at an xfce4 desktop with a lighted keyboard and mouse attached to it. It came with a 110-240 to 19VDC 3A power supply.
I'd say the cheap ac to dc power supply it came with is no more than 80% efficient so 6.56W DC would be what I might expect to see if I peeled apart its DC feed side power cable and put a precise clamp ammeter around it.
Absolutely maxed out with stress-ng it's 24.6W at the wall.
I can see this argument both ways. On the one hand, logically you'd expect the last assignment to take precedence, like the style attribute. On the other, conflicting styles don't make sense.
The random outcome, entirely dependent on the Tailwind generation internals, is the worst of all worlds though, it's just an unfortunate side-effect of relying on cascading sheets to drive atomic styles.
It’s random sure, but it’s also reliably random. This is one of the few footguns that exist in tailwind and luckily it’s super easy to catch. The IDE plugins will give you a warning if you apply multiple classes that manipulate the same attribute and there is no reason you also can’t catch it in CI.
Is it ideal? I guess not, but there are a lot of weird gotchas and footguns in CSS too. Just because they’re in the language doesn’t make them magically more or less of a problem. For a similar weird mental shift, consider adding @starting-style and the native popover open attribute. All the good tutorials online have a warning about cascade order because as a human reading it, it can seem wrong or backwards.
Kevin Powell’s most recent video about animating display: none covers it if you want a concrete example.
Sometimes true, but one issue here is that because Tailwind utility classes vary from being a 1:1 mapping to a single underlying style rule, to mapping to several, it's not always obvious which classes will conflict.
Note that we're talking about an edge case for an authoring error - applying two conflicting styles to an element does not make sense, it has no defined behaviour, and is correctly flagged by linting tools as such.
Should Tailwind really go out of its way to pay a compile time tax, just to make this case resolve predictably? Or should people rather use code editors that point out invalid duplicated styles, which are always added in error?
Works out of the box with OpenRouter for most models. Some providers are a bit flaky, but DeekSeek (provider) has been one of the most reliable for me, no problems hitting >99% CH.
That's fair, each provider maintains their own cache. OpenRouter does make an effort to keep providers "sticky", but it may hop/stick to another if latency is too high.
If you don't care about latency, you can create a preset with a single provider, then use that as the model key (i.e. `@preset/deekseek-v4-excl`). The only real downside is OpenRouter's service fee. If you don't want the convenience of switching models, or their excellent dashboard, it's definitely better to pay the provider directly.
I find myself often trying to understand the madness of some of the code an LLM produces. Does that count? You're absolutely right! I made a mistake, and I'm sorry.. Then I end up questioning myself if it wouldn't have been easier to just do it myself. To be fair though, it's not limited to LLMs, I've felt that way other people's code too.
Jokes aside, there's a difference to understanding the code and understanding the reasoning that is behind the code, I feel that LLMs still struggle enormously with the later. They start writing, and sometimes realise halfway through that they can't backtrack and just keep writing rubbish. You can argue about spinning loops and iterative processes, as long as they are actually able to converge.
I noticed something about LLM code generation and this is as good as place to post the finding as any.
It's fairly obvious, but as we know LLMs choose the highest probability next token, so when generating code, it does so from left to right, without ever reorganizing, which unless it uses a harness, that's not how WE write code, that's property 1.
Property 2 is that it will write out as many boilerplate that occurs before the actual implementation as it can, because boilerplate is always the same, and implementation is high temperature/chaotic, there's many different ways an implementation can go. For example in python, you can write your code directly, or wrap it in a main loop and later add a main guard. LLMs will always write the main loop, since it's not competing with NOT writing a main loop, it's competing with the best option in the set of non-main loop solutions. This is trivial in this case because all non main solutions are present in the main loop solution set, but for solutions where the two sets are distinct, the LLM will have a bias towards solutions that share initial tokens, e.g:
Solution 1: import lib1 and use function A 30%
Solution 2: import lib1 and use function B 25%
Solution 3: import lib2 and use function A 45%
Despite solution 3 being weighted more heavily, the LLM will opt for solution 1, since solution 2 makes it choose the import lib1 token.
This pushes towards mega-libraries instead of composable Unix libraries. Stuff like numpy, react or helper libraries get a boost since they are more like megaframeworks than specific libraries, and they get their import statements boosted.
I think I get your point. I can't say that I've observed it writing boilerplate just for the sake of it, but it is disproportionately/abundantly present in the training set. One of the first rules they teach in ML is to balance datasets, even if it's with fake/interpolated samples.
The linear L->R generation is definitely a thing, it's much more costly for an LLM to iterate edits, where a skilled vim coder will be jumping all over the place, trying to make all the LEGO pieces fit.
The skill therefore relies on just being able to one-shot entire chunks of code correctly, and it's amazingly good at this... But even the SOTA models still have a lot of unused imports and unused variable declarations. They just have to "guess" what they'll need and hope for the best. If they include a mass of numpy/scipi/react/icon imports that they might need, it opens the landscape for them later on when predicting relevant tokens, reaching a more ideal solution.
It doesn't hurt to add imports that might be helpful, rather than penalize the solution because you haven't got them. Although the last few SOTA models are more "harness/tool aware", they're starting to have the instinct to write the code anyway, and to be allowed to go and fix the imports later via tool calls.
For anyone who's seen the film Arrival (2016), their entire language is formed of complete concepts, not sequences of words and time. I keep thinking back to this.
Sorry for skipping over your actual argument, but if it hinges on that assumption then it's probably moot. I'd assume almost all ai generated code that makes it into codebases is produced using a harness.
if it uses a harness, the effect is still there, just piled on and magnified.
I sometimes gen code without a harness and copy paste it or manually type it, maybe I can do like 200 lines in a day? Whenever I see someone coding with a harness it's like 100x times that, so this phenomenon will happen hundreds times more.
To be honest, living in Switzerland and speaking with peers, we're just exhausted by the constant AI hype. For a lot of us, the fact that Europe isn't frantically trying to scrape the entire internet and every book in existence for the next massive model isn't a bad thing. The big players are doing their thing, like with the nuclear arms race. We regulate a lot, too much a lot of the time, but sometimes that trickles down to other places too. A lot was done right, imo.
ETH Zurich and EPFL universities recently put out an open model called Apertus (was on the HN front page a few months back), it's not a frontier model, but they built it properly regarding copyright and data transparency.
It might look a bit slow or old-fashioned, but focusing on doing things ethically and legally feels like a much better path than just joining the race to scrape everything.
Sir, I would suggest that if Europe fails to be economically competitive, the downstream implications on European society will produce much worse outcomes than (for instance) data transparency…
Doing things with ethical intentions does not necessarily produce outcomes that are beneficial for society at large.
I'm inclined to agree with you, but you could make the same argument for exploiting natural resources and the environment. I don't think it's being done right at the moment, and it does not seem to be benefiting people as much as certain companies.
Well, is this mad dash for AI producing "outcomes that are beneficial for society at large" yet? So far it looks like its mostly producing a ton of negative externalities and wealth transfer to corrupt elites.
Also, no, abandoning ethics is not an option, what a ridiculous suggestion.
it's horrible that Europe is so backwards in AI. too much regulation and nothing to show for it. we should be way faster.
there is no money. the culture in both Europe and Switzerland is that you don't fail, while in the US it's perfectly fine to be on your 4th startup because the first 3 failed.
it's not that it LOOKS slow and old fashioned, it IS slow and old fashioned. it's horrible.
If these models ever reach the point where they are as good a programmer as a human is (and thus can self-improve completely independently), then there won't be an independent Switzerland much longer. AI race is a race for first place.
> like with the nuclear arms race
MacArthur was about to nuke the Chinese in the Korean war. China knows that nuclear weapons, AI and robotics are a matter of survival and not a nice-to-have.
> We need open weights companies now more than ever.
If you're objective it to democratize AI, sure. But for those fed up with it and the devastating effects it's having on students, for example, can opt to actively avoid paying for products with AI (I say this as someone who uses it every day, guilty). At some point large companies will see that they're bleeding money for something that most people don't seem to want, and cancel those $100k/mo deals. I've already experienced one AI-developer-turned company crash and burn.
Personally, I don't think this LLM-based AI generation will have any significant positive impacts. Time, energy (CO2) and money would have been far better spent elsewhere.
There's plenty of valuable use cases for being able to give natural language instructions to a tool and have it act on that input. I do however agree that the current hype and valuations far exceed the real value being offered.
Like with the dot com bubble there will be a crash and then whatever shakes out of that will be the companies and products who invested in understanding the actual strengths and weaknesses of the tech, instead of just trying to slap an "AI" sticker on everything.
Being a moderately frequent user of Opus and having spoken to people who use it actively at work for automation, it's a really expensive model to run, I've heard it burn through a company's weekend's credit allocation before Saturday morning, I think using almost an order of magnitude more tokens is a valid consumer concern!
I have yet to hear anyone say "Opus is really good value for money, a real good economic choice for us". It seems that we're trying to retrofit every possible task with SOTA AI that is still severely lacking in solid reasoning, reliability/dependability, so we throw more money at the problem (cough Opus) in the hopes that it will surpass that barrier of trust.
You could make the same argument for any language. It still requires you to think and implement the solution yourself, just at a certain level of abstraction.
This stands to reason. If you need to bridge different languages together like in your case, they need to speak a common tongue. REST/GrahQL/gRPC solve this problem in different ways. There is no technical limitation keeping you from serving HTTP traffic from Erlang/Elixir, but from my own experience it isn't a pleasant experience. JavaScript or Python are dead simple, until you realise that 64-bit integers are not a thing in JS, and need to be handled as strings. Similarly, tuples will give you hell in Python.
On the other hand, if you don't need to cross that boundary, the BEAM will very happily talk to itself and let you send messages between processes without having to even think about serialisation or whether you're even on the same machine. After all, everything is just data with no pointers or cyclic references. That's more that can be said for most other languages, and while Python's pickle is pretty close, you can probably even share Erlang's equivalent of file descriptors across servers (haven't tried, correct me if I'm wrong), which is pretty insane when you think about it.
> I have found the real value of Erlang to be internally between trusted nodes of my own physical infrastructure as a high-level distributed "brain" or control plane
I think this is pretty high praise, considering it's about as old as C and was originally designed for real-time telephone switches.
> There is no technical limitation keeping you from serving HTTP traffic from Erlang/Elixir, but from my own experience it isn't a pleasant experience.
I would be interested in what was unpleasant? I've run inets httpd servers (which I did feel maybe exposed too much functionality), and yaws servers and yaws seems just fine. maybe yaws_api is a bit funky, too. I don't know the status of ACME integration, which I guess could make things unpleasant; when I was using it for work, we used a commercial CA, and my current personal work with it doesn't involve TLS, so I don't need a cert.
> you can probably even share Erlang's equivalent of file descriptors across servers (haven't tried, correct me if I'm wrong)
Ports are not network transparent. You can't directly send to a port from a different node. You could probably work with a remote Port with the rpc server, or some other service you write to proxy ports. You can pass ports over dist, and you can call erlang:node(Port) to find the origin node if you don't know it already, but you'd definitely need to write some sort of proxy if you want to receive from the port.
Perhaps I was a little harsh, this was a few years back when I was evaluating Elixir for a client, but ended up going back to a TS/Node.js stack instead. While the Phoenix documentation is stellar, I found it difficult to find good resources on best practices. I was probably doing something stupid and ran into internal and difficult to understand exceptions being raised on the Erlang side, from Cowboy if I recall. In another case, I was trying to validate API JSON input, the advice I got was to use Ecto (which I never really groked) or pattern match and fail. In JS, libraries like Zod and Valibot are a dream to work with.
The result was a lot of frustration, having been thoroughly impressed by Elixir and Phoenix in the past, knowing that I already knew how to achieve the same goal with Node.js with less code and would be able to justify the choice to a client. It didn't quite feel "there" to pick up and deploy, whereas SvelteKit with tRPC felt very enabling at the time and was easily picked up by others. Perhaps I need another project to try it out again and convince me otherwise. Funnily enough, a year later I replaced a problematic Node.js sever with Phoenix + Nerves running on a RPi Zero (ARM), flawless cross-compilation and deployment.
No, they aren't. You have to use BigInt, which will throw an error if you try to serialise it to JSON or combine it with ordinary numbers. If you happen to need to deserialise a 64-bit integer from JSON, which I sadly had to do, you need a custom parser to construct the BigInt from a raw string directly.
reply