Did they not target code tasks for this LLM, or is it genuinely that bad? Pretty embarrassing when your shiny new 400B model barely ties a 32B model designed to be run locally. Or maybe is this a strong indication that smaller, specialized LLMs have much more potential for specific tasks than larger, general purpose LLMs.
The commonly given response to this question is two-fold, and both parts have a similar root cause: smart pointers and "safety" being bolted-on features developed decades after the fact. The first part is the standard library itself. You can put your data in a vec for instance, but if you want to iterate, the standard library gives you back a regular pointer that can be dereferenced unchecked, and is intended to be invalidated while still held in the event of a mutation. The second part is third party libraries. You may be diligent about managing memory with smart pointers, but odds are any library you might use probably wants a dumb pointer, and whether or not it assumes responsibility for freeing that pointer later is at best documented in natural language.
This results in an ecosystem where safety is opt-in, which means in practice most implementations are largely unsafe. Even if an individual developer wants to proactive about safety, the ecosystem isn't there to support them to the same extent as in rust. By contrast, safety is the defining feature of the rust ecosystem. You can write code and the language and ecosystem support you in doing so rather than being a barrier you have to fight back against.
Yep. Safe rust also protects you from UB resulting from incorrect multi-threaded code.
In C++ (and C#, Java, Go and many other “memory safe languages”), it’s very easy to mess up multithreaded code. Bugs from multithreading are often insanely difficult to reproduce and debug. Rust’s safety guardrails make many of these bugs impossible.
This is also great for performance. C++ libraries have to decide whether it’s better to be thread safe (at a cost of performance) or to be thread-unsafe but faster. Lots of libraries are thread safe “just in case”. And you pay for this even when your program / variable is single threaded. In rust, because the compiler prevents these bugs, libraries are free to be non-threadsafe for better performance if they want - without worrying about downstream bugs.
I've written some multithreaded rust and I've gotta say, this does not reflect my experience. It's just as easy to make a mess, as in any other language.
Me too. I agree that its not a bed of roses - and all the memory safety guarantees in the world don't stop you from making a huge mess. But I haven't run into any of the impossible-to-debug crashes / heisenbugs in my multithreaded rust code that I have in C/C++.
Most likely because it all multi-threaded code access in-memory data structures, internal to the process memory, the only scenario in multi-threaded systems that Rust has some support for.
Make those threads access external resources simultaneously, or memory mapped to external writers, and there is no support from Rust type system.
> Make those threads access external resources simultaneously, or memory mapped to external writers, and there is no support from Rust type system.
I don’t think that’s true.
External thread-unsafe resources like that are similar in a way to external C libraries: they’re sort of unsafe by default. It’s possible to misuse them to violate rust’s safe memory guarantees. But it’s usually also possible to create safe struct / API wrappers around them which prevent misuse from safe code. If you model an external, thread-unsafe resource as a struct that isn’t Send / Sync then you’re forced to use the appropriate threading primitives to interact with the resource from multiple threads. When you use it like that, the type system can be a great help. I think the same trick can often be done for memory mapped resources - but it might come down to the specifics.
Shared memory, shared files, hardware DMA, shared database connections to the same database.
You can control safety as much as you feel like from Rust side, there is no way to validate that the data coming into the process memory doesn't get corrupted by the other side, while it is being read from Rust side.
Unless access is built in a way that all parties accessing the resource have to play by the same validation rules before writting into it, OS IPC resources like shared mutexes, semaphores, critical section.
The kind of typical readers-writers algorithms in distributed computing.
Safe rust prevents you from writing data races. All concurrent access is forced to be guarded by synchronization primitives. Eliminating an entire class of bugs.
You can still create a mess from logical race conditions, deadlocks and similar bugs, but you won’t get segfaults because you after the tenth iteration forgot to diligently manage the mutex.
Personally I feel that in rust I can mostly reason locally, compared to say Go when I need to understand a global context whenever I touch multithreaded code.
The standard library doesn't give you a regular pointer, though (unless you specifically ask for that). It gives you an iterator, which is pointer-like, but exists precisely so that other behaviors can be layered. There's no reason why such an iterator can't do bounds checking etc, and, indeed, in most C++ implementations around, iterators do make such checks in debug builds.
The problem, rather, is that there's no implementation of checked iterators that's fast enough for release build. That's largely a culture issue in C++ land; it could totally be done.
I plan on buying one, and I have a 3 year old android phone. I would have upgraded sooner, but I basically wanted an iphone 14 but with USB C so I don't have to get new cables. Now I can get that.
USB C is definitely more universal, it is used for laptops and peripherals and other random devices. Qi charging is mostly limited to phones and certain phone accessories, which usually also have USB C.
> Which is generally undesirable for commercial projects; especially early in their lifecycles when bugs may be present and would be best kept private until the project has been more battle-tested.
Copyleft only kicks in on redistribution. If you're only testing internally, you don't need to distribute source code. It's only once you distribute that software that you also need to distribute source.
Say I use a software with AGPL as license on my server. If my server doesn't output anything AGPL-licensed to its clients, where is the distribution? If there is no distribution, how can the AGPL be enforced?
> If my server doesn't output anything AGPL-licensed to its clients,
The IP (intellectual property) of the code has no relationship whatsoever with the IP of the content being served by the served.
> where is the distribution?
You setting up a production server counts as “distributing the service” in AGPL's definition, as AGPL is aimed directly at the SaaS business model.
So if you use an AGPL software on your server, you need to provide the source code (including any changes/customization you've made) to your users. BTW this is a common misconception with GPL, nobody forces you to publish the code in public like on github or anything, it could be behind a login form reserved to your customers only. But you need to give them to your customers under the same AGPL license, so if they want to publish it on github themselves, or fork it and make a business out of it, they can.
The desktop application is the easiest way to get up and running on Mac or Windows where a VM is necessary. Of course you can still set up docker engine manually in a VM, but even then it doesn't offer the same level of integration, like host mounts, Rosetta on Mac. Desktop Linux is the only environment where the desktop app offers little benefit over just running the engine.
I always forget there's people who do software development on something other than Linux.
I mean I use Windows too (my laptop has poor Linux support, plus Proton wasn't a thing when I bought it so I went for something which is guaranteed to run games well). But I do all my development in a Linux VM in Virtualbox. If you have an SSD, performance is indistinguishable from native.
> If you have an SSD, performance is indistinguishable from native.
In my experience this is very much not the case. Running a graphical linux desktop in a VM on beefy hardware still introduces noticeable keypress latency for me, as an example.
