401 karma · joined September 21, 2020
Does anyone else find this outright insane? It wrote the equivalent of a full-length novel, just to sit in the question of planning a few dozen shapes.
Academia is going to love this :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
> Ports are not network transparent
I stand corrected, thank you for the explanation!
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.
> This function is not magic; it is literally defined as: pub fn drop<T>(_x: T) {}
This is usually more deterministic than GC languages (no random pauses), but can be less efficient for highly nested data structures. It also makes linked lists impossible without using "unsafe rust", as it doesn't abide by the normal ownership rules.
[1]: https://doc.rust-lang.org/rust-by-example/scope/raii.html [2]: https://doc.rust-lang.org/std/mem/fn.drop.html
The main limitation is likely offline apps, LiveView requires a persistent connect to the server. I doubt this is something you'll encounter for your use case.
- Single lightweight binary install and executable (~6 MB), clean uninstall
- Automatic updates (digitally signed, uploaded to a small VM)
- Integrates nicely with SvelteKit and TailwindCSS
- The Rust backend was able to integrate with GTSDK over FFI. The cmake crate made C++ compilation and linking automatic as part of cargo build, provided that a C++ toolchain is available (no problems even on Windows).
- No scary toolchain setup with a load of licenses to review and accept (looking at you, Flutter. I'm a student, not a lawyer. Although perhaps this will also be a thing with Tauri + Android?)
For a small project, I can't recommend it enough. I wouldn't know where to start with a C# or Qt GUI application, especially if I wanted to make it cross-platform.
It'll be interesting to see if it gains any traction in the mobile space. Flutter is great and may be better optimised for certain rendering techniques, such as infinite lists, but sticking with web technologies is a very compelling advantage.
That being said, I do like inspecting the source from time to understand it better, or make up for missing documentation. Sometimes though, with this being JS, I wish that I could unsee the things that I've seen, code that production depends upon, deep within the dependency tree.
I agree with the idea of fluency when writing without types, but for me it's not about how fast you can write code. Code for me is a lot of rereading and understanding what the hell you wrote just a few days ago, I find typed code easier to get back into and it's faster to find things that broke in parts of the codebase that you're less familiar with when you change something.
I also agree with your other statement. I think Rust tries to abstract a lot of behind into its own type system, such as Box<T> for pointers, whilst keeping it relatively fast. C is definitely the right tool for the job if you want direct memory access, I also think this is a relatively small proportion of people, working on OS, embedded systems or mission critical systems such as flight control/medical equipment.
To address some of your complaints: yes, there are a lot of concepts to understand. I like wrappers, I found it crazy that in C, you first declare a mutex_t variable, and then you specifically have to call chMtxObjectInit(*mutex_t mutex) to initialise it [1]. If you forget? UB, kernel panic sometime in the future. I think Mutex::new() is far cleaner, and it's namespaced without arbitrary function prefixes. Binaries are tiny in comparison to JS/Python with deps, they will be larger than C. Compile times aren't that slow and you can't make extra language features happen out of thin air.
In C, I've found that it's commonplace to do a lot of clever and mysterious pointer and memory tricks to squeeze out performance and low resource utilisation. In embedded, there's usually a strong inclination to using "global" static variables, even declaring them inside function bodies because it "limits the visibility/scope of the variable". Not declaring a static variable inside a function is what knocked a few points off my Bachelor's robotics project.
I personally don't like this. It puts a lot of pressure on the programmer to understand the order of execution, and keep a complex mental model of how the program works. Large memory allocation, such as a cache, can be hidden in just about any function, not just at the top of a file where global variables are usually defined.
It sounds like what you're trying to accomplish is inherently unsafe, hence the "preaching", as in it requires the programmer's guarantee that 1) the data is fully initialised before it's accessed and 2) once the data is initialised, it's read-only and can therefore safely be accessed from other threads. C doesn't care, it will let you do a direct pointer access to a static variable with no overhead. Where's the cost? The programmer's mental model. I haven't tried, but I imagine that Rust's unsafe block will allow you to access static variables, just like in C with no overhead, effectively giving your OK to the compiler that you can vouch for the memory safety.
Rust solutions: lazy_static crate (safe, runtime cost in checking if initialised on every access), RwLock<Option<T>> (safe, runtime cost to lock and unwrap the option), unsafe (no overhead, memory model cost and potentially harder debugging), extra &T function parameter (code complexity cost, "prop-drilling", cleaner imo). On modern hardware, the runtime cost is absolutely negligeable.
Why would you not want to use Rust for a large project? This seems a bit contradictory to me. The safety guarantees in my opinion really pay off when the codebase is large, and it's difficult to construct that memory model, especially with a team working on different parts. Instead, you overload that work to the compiler to check the soundness of your memory access in the entire codebase.
If you like C, by all means keep on using it, I enjoyed my forray into C, it's simple and satisfying, but would much prefer Rust, after spending a lot of time tracking down memory corruption. Rust's original design purpose was to reduce memory bugs in large-scale projects, not to replace C/C++ for the fun of it. We usually have a natural inclination to what we know well and have used for a long time. Feel free to correct me if something is wrong.
1: http://www.chibios.org/dokuwiki/doku.php?id=chibios:document...
> If the function does panic (or the compiler fails to prove that the function cannot panic), the program fails to compile with a linker error that identifies the function name.
Python focuses on being simple, interpreted and dynamicaly typed, Rust requires you to specify the exact types of all the things (like C/C++) which allows it to generate really optimal compiled machine code before execution, it has more information to work with. Accessing a struct/"object" field is not a hash table lookup, it's a direct pointer access, as the exact size of things are known at compilation time.
If you're writing a script, a tool, a small game, it's simpler to use Python. If you're writing a database engine, a mission-critical piece of code that has to behave predictably without the possibility of random GC pauses, anything that has realtime constraints such as audio, lower-level languages like C, C++ and Rust are a must.
A lot of higher-level folk seem to enjoy Rust as well, especially in networking/the web, for whom the speed is worth the additional difficulty and complexity.
The Result<T,E> type is very explicit, and can be easily ignored, composed or "re-thrown" with the "?" suffix without nested try/catch blocks. Return value based error handling is something Go, Elixir and other more functional languages have also adopted.
Panic is there to aleviate the really exceptional circumstances, when the trade-off for possible program termination is worth the much simplified error handling, such as when casting to a smaller integer type in case of overflow, or locking a mutex when it may be in a posioned state (which, funnily enough, can arrive when a panic occurred whilst the mutex was previously locked, i.e. the mutex guard is dropped during a panic).