This is spot on. I am extremely uncomfortable with the large number of transitive dependencies that end up in pretty much any non-trivial rust application. No amount of memory safety will save us if a tiny, ubiquitous library that nobody scrutinizes because it’s nested eight layers down the dependency graph gets compromised.
I think Go apps tend to have better dependency hygiene because the language has a better standard library, which results in better culture around dependencies.
I also think it’s frustrating that both cargo and npm totally ignore the decades of prior art from Linux distributions that have figured out good ways to improve dependency management. We’d be in better shape if there was a community curated subset of known-good dependencies that are release-managed together that the broader ecosystem could build on, sort of like Ubuntu having “main” and “universe”.
I learned programming from C# which has an excellent standard library. Just recently started using Go which seems to have a good standard library. Been using python for years, can't say I ever had a complaint about the standard library.
Rust meanwhile seems to be following some "no standard library" philosophy.
I feel like there's an opportunity out there to become like an amoeba: fund and build a third party Rust standard library, absorb absolutely everyone who is so grateful to have a library, and then get so big absorb Rust itself.
> Rust meanwhile seems to be following some "no standard library" philosophy.
As an embedded dev, I personally find it very useful to compile Rust programs without a standard library. I would not use C# or Python for an embedded project for the reasons you probably prefer them for your projects.
The guide that NASA put out for spaceflight systems was on HN earlier this year and one of the rules is "no heap allocations; all memory must be declared and fixed size for the life of the app." Isn't Rust the ideal language for that kind of limitation? We are talking C, C++, Rust, Zig as options I would guess; Rust certainly seems the ideal from those options.
But you gotta admit people trying to build GUI libraries and using linked lists don't fit.
I think one thing that has made Go have better dependency hygiene is not merely having "batteries included" in the standard lib, but the early focus on having production-ready implementations of a lot of stuff in the standard lib, as opposed to minimum viable implementations. I used to get a long way with one or two dependencies that would barely fan out at all. It's been a while since I worked on a Go project, so I'm not sure if it's still that way.
I think having production-grade implementations makes a huge difference also. Go’s net/http in the std lib feels like a good example of that, though I’m fairly new to go still. But it seems net/http still gets pretty big updates despite something like Chi being available as an external lib. Odin is doing this as well, even including raylib in the std lib. Odin is even more primed to keep you on the std lib as it doesn’t include a package manager at all.
So I went to have a look at Odin and was mind blown at the lispiness in the hellope example. A list of operators defined as "program"; that are applied to the accumulator then printed. It's a striking first impression for me and I want to see what the Odin people have cooked up.
Odin has been a masterpiece so far! Ginger Bill has a massive update coming in for it Jan 2027 as well. :) I think it's definitely going to take off in the next few years.
I wasn't when I saw they made the exact same stupid error as Python: if and switch are statements, so that you need a stupid ternary operator to do the same.
I think Go ends up with fewer dependencies mostly because there is more friction in finding them. With rust (and npm) you just "cargo search xxx", then "cargo add xxx". Go makes you web search and poke around github looking for something. It's not onerous or anything, but just that extra step slows things down just a bit. C projects tend to have the least because it's even more annoying to add them and you have to create build commands that deal with slightly different distributions (and learn makefile+pkg-config or cmake, or autoconf).
Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason.
I don't really agree. You reach for a dependency when you need to do something non-trivial and the stdlib doesn't have what you need (or the stdlib implementation is bad). You don't just sit around running `cargo search` for fun.
I think the ease of adding dependencies does drive the idea of "microdependencies", where you have many dependencies that do one little thing, and then those dependencies likely have their own small dependencies.
Whereas in the C world, you'll probably have a smaller number of dependencies, but it's likely that some of them are very big dependencies that offer a lot of functionality (like glib, for example).
I could maybe see the argument that ease of adding dependencies discourages people from writing small things themselves. Good ol' left-pad comes to mind. In an ecosystem like C, I'd just write that algorithm myself, over and over and over, because pulling in a dep just for that feels annoying.
> Certainly having a larger stdlib helps Go projects keep their deps down, but I don't think it's the real reason
I disagree: having a big stdlib that encompasses a huge chunk of common functionality (logging, a plethora of network server/client protocols, etc) means that for basic needs, the question of 3rd party libs never arise, whereas for other language, the question is not if you need a dep, but which one. Making gorilla easier to find won't undo the cultural reluctance of adding a 3rd party dep when using the (very pragmatic, IMO) stdlib server is adequate to the task.
Perhaps, but I think it depends on where the Go devs are coming from. In my experience the lack of proper dependency management in older versions of Go didn't really lessen dependencies, it just made teams have to deal with annoying $GOSRC issues. But then I worked at a place where the devs used PHP (w/composer) and node before Go was introduced.
Personally I came from a C background so I tended to use deps more sparingly.
In the end it's a bit of a balancing act—lots of dependencies is a larger opportunity for these kind of supply chain attacks to affect you. Copying stuff into your repo protects you from that, but it also makes it way more likely that you'll miss security fixes, unless you're actively looking for them. Re-implementing what you need is also viable but it slows down the dev process.
I agree. Java has the same ability to quickly add deps, and in some case they can be sprawling, but it's still perfectly possible to develop complex apps without a lot of deps coming in.
It absolutely is a culture thing. I've seen many threads asking about backend frameworks in Go, and every time there were lots of answers akin to "screw framework dependencies, stdlib is more than enough".
At upload time? Or by every client at download time? Or just adhoc by random users?
This does sound like an excellent way of improving automated package checks, even if it does result in some false positives and false negatives. For all sorts of packages, not just code dependencies.
By security scanners, the moment a crate is uploaded to crates.io. The way forward here is dependency cooldowns enabled by default for ordinary users (and crates.io changed to show the old version until the new one is a day or two old). Essentially, security scanners get to vet a package for a day or two before ordinary users see it in everyday development.
You are just shifting where the eyes are, the amount of eyeballs (developer time) is the same. Unless the proposal is to increase the amount of (other) developers time.
The proposal ends up amounting to either shifting stuff around, or asking to other people to put in more effort? Into a project that usually doesn't pay (programming languages and runtimes)
Which by the way, asking other people to do stuff for free IS the attack vector, if you are the kind of dev or company that gets hit by these, your ultimate root cause is that your business strategy is using code without paying for it. No such thing as a free lunch, you will pay for it, among other things, with an increased cybersecurity risk.
Packages can release updates arbitrarily, while standard libraries tend to have longer release cadences.
It's also more difficult to put arbitrary code into an stdlib, because stdlibs are scrutinized better.
Also, it's harder for some random anonymous developer to gain push access to stdlib repository.
One of the reasons so much Rust code is in libraries is not because there are no people to write it (duh), but because putting these in std commits maintainers to keeping backwards compatibility and slows down included package's release cycle.
I’ve been really impressed with GPUI, particularly with Longbridge’s open source component library which provides a bunch of shadcdn-alike widgets that are really well implemented and come with a bunch of tailwind-like helper functions that make layout easy.
The downside is that the dependency stack you need to do gui programming with rust is massive and the compile times are brutal. You can’t beat the application performance, though. It’s crazy how nice it feels compared to bloated electron apps.
The question of “are we gui yet” is definitely yes, at least on the desktop. The problem is that developers are too lazy to build apps with anything other than web frameworks.
Can certainly be a downside. Jaded / grumpy rust programmer perspective: I will take this over the typical rust pattern of OSS libs which have been made without being tested in practical applications!
For me it's not so much laziness, as more of a lack of desire to rely on a framework that Zed core team still feels to be not ready for a general release. Electron just happens to be the least worst way to make an aesthetically pleasing cross-platform desktop app, but the performance trade-off is a major pain point.
GPUI getting the public release greenlight will no doubt be a turning point for desktop GUI development. All it took is a small team of gifted developers to dogfood their own GUI toolkit and get some much-needed VC backing. The future looks very bright.
I made side-by-side comparison with this and egui. Equi win with the less amount of code required for most things. But GPUI must be excellent for bigger projects where you need better architecture for components.
I’ve been using GPUI in a side project of mine (TukeySheets.com) and can attest that it is quite nice and it works well on all platforms, at least in my experience. So I would say, definitely “we are gui” in rust.
The component library by long bridge is also well done and reasonably well documented.
This is great. In recent years the Rust has been talked about so much in regards to the web
. It us getting better and more technologies are being developed tk further this. I am very impressed in what im seeing now. There are some amazing techniques.
I bought one of these last year, specifically looking for a modern take on the netbook form factor. I run PopOS on mine and absolutely love the machine. It’s a perfect travel laptop and it has largely replaced the iPad mini that I previously used as my travel companion. I sometimes use it with XReal glasses, which is great. I’ve found that a 35 watt phone charger is sufficient to charge it over USB C, so I don’t even need to carry a laptop-class charging brick.
I will note that I also had the screen rotation issue described in the post, but it was easy to solve at the desktop environment level in COSMIC. I didn’t bother dealing with it elsewhere because I honestly don’t mind if the grub menu is sideways.
Yes, I’d be wary of going anywhere near this for that reason alone. You can’t just say “the keyboard is terrible” but then that you still like it overall -- more detail needed!
Yeah, in particular it looks like the complaint was about having to hit the center of the keys exactly, which seems quite bad.
I’ll learn a weird layout for a netbook, some compromise is expected to get the small size (side note: I think “unfamiliar layout” issues are over-represented in reviews because they usually describe the reviewer’s experience when they are first getting used to the device, I get used to a layout in the medium term anyway and then it isn’t really a problem anymore (side side note: we should separate out the concepts of unfamiliar and bad layouts, they are different things, the former is overcome over time, the latter gives you repetitive stain injuries over time)).
Having the nail the keys in the middle, though, is just a sign of poor keyboard design. That probably won’t be overcome, if anything it is a sign of bad build quality and will probably get worse over time.
I've wanted to see a good, production-quality open source take on this editing paradigm for a long time and your implementation appears to get a lot of things right. I took a crack at this myself a few years ago but never got around to really getting it over the line: https://github.com/segphault/codemirror-rich-markdoc
Your wysiwyg support for tables is very nice, but I couldn't quite figure out how to delete a row. The checkboxes are also a little fiddly, it would be nice if the checkbox turned into editable text when the cursor moves next to it. Does Atomic Editor work with vim bindings via replit's CM6 vim plugin?
Props for building this and sharing it, I hope you stick with it.
Anthropic uses Stainless Docs for the API reference. It’s a custom integration that embeds the Stainless Docs react components directly in the Claude dashboard application.
(I worked on the Stainless Docs product at Stainless and implemented support for Anthropic’s embedding use case)
It's bad enough that Microsoft doesn't have a satisfying answer to this question, but what makes it worse is that WinUI feels weirdly non-native in ways that sort of uncomfortably result in Electron apps feeling more like real Windows applications.
It's worth noting though that Apple is on a similar trajectory and is now in a very nearly as bad position given all the serious issues with SwiftUI and how badly it has fragmented/degraded Mac desktop application development.
It's almost like the major desktop platform vendors have all given up on supporting high-quality native desktop applications.
> It's worth noting though that Apple is on a similar trajectory and is now in a very nearly as bad position given all the serious issues with SwiftUI and how badly it has fragmented/degraded Mac desktop application development.
Apple (and Next before it) have been iterating on Appkit/UIKit for three and a half decades.
Now they have added SwiftUI as a second option and have been iterating on it for a bit over half a decade.
This is in no way similar to Microsoft creating and abandoning another UI framework every couple of years.
If Microsoft had been steadily improving Win32 all these years, where would it be today?
This was my most-wanted Obsidian feature, so I’m thrilled to see this. It’s going to be great for server-side automation and RAG against Obsidian vaults.
What? The window manger and the panel (plasmashell) are separate processes in a Plasma desktop. In Sway, users typically choose from a range of totally separate applications like swaybar or quickshell for the panel. There’s absolutely no reason the panel has to be coupled with the compositor under Wayland and nobody actually does it that way that I’ve seen.
I think Go apps tend to have better dependency hygiene because the language has a better standard library, which results in better culture around dependencies.
I also think it’s frustrating that both cargo and npm totally ignore the decades of prior art from Linux distributions that have figured out good ways to improve dependency management. We’d be in better shape if there was a community curated subset of known-good dependencies that are release-managed together that the broader ecosystem could build on, sort of like Ubuntu having “main” and “universe”.