Not entirely true - e.g. Kotlin has null safety built into its type system, and I find it much nicer than the option/optional approaches used in various other languages.
Agreed, and the small stdlib is one of the main reasons for this problem. I understand the reasoning why it's small, but I wish more people would acknowledge the (IMHO at least) rather large downside this brings, rather than just painting it as a strictly positive thing. The pain of dealing with a huge tree of dependencies, all of different qualities and moving at different trajectories, is very real. I've spent a large part of the last couple of days fighting exactly this in a Rust codebase, which is hugely frustrating.
(I've been on libs-api, and libs before that, for 10 years now.)
API Stability. When the standard library APIs were initially designed, "the Python standard library is where packages go to die" was very much on our minds. We specifically saw ourselves as enabled to have a small standard library because of tooling like Cargo.
There are no plans for Rust 2.0. So any change we merge into std is, effectively, something we have to live with for approximately forever. (With some pedantic exceptions over edition boundaries that don't change my overall point.)
Nuance is nearly dead on the Internet, but I'll say that I think designing robust and lasting APIs is a lot harder in Rust than it is in Go. Rust has a lot more expressiveness (which I do not cite as an unmitigated good), and the culture is more heavily focused on zero-overhead abstractions (which I similarly do not cite as an unmitigated good). That means the "right" API can be very difficult to find without evolution via breaking changes. But the standard library cannot, generally speaking, make breaking changes. Crates can.
I would suggest not reading the OP as a black-and-white position. But rather, a plea to change how we balance the pros and cons of dependencies in the Rust ecosystem.
I can understand not wanting to add SMTP or CGI to the stdlib. But a lot of common POSIX functionality (which is sometimes a single syscall away) is missing too.
A lot of common POSIX functionality is not missing though. I was able to write ripgrep, for example, by almost entirely sticking to the standard library. (I think the only place I reach out to `libc` directly is to get the hostname of the current system for rendering hyperlinks in your terminal.)
We also came at the standard library with a cross platform mentality that included non-POSIX platforms like Windows. You want to be careful not to design APIs that are too specific to POSIX. So it falls under the same reasoning I explained above: everything that goes into std is treated as if it will be there forever. So when we add things to std, we absolutely consider whether the risk of us getting the API wrong is outweighed by the benefit of the API being in std in the first place. And we absolutely factor "the ease of using crates via Cargo" into this calculus.
I peeked at the code for gethostname in ripgrep, and it's nice and straightforward.
Much like op said here; we have a culture of "don't write unsafe code under any circumstance", and we then pull in a dependency tree for a single function that's relatively safe to contain. It solves the problem quickly, but at a higher price.
BTW, thanks for ripgrep. I don't actually use it, but I've read through different portions of the code over recent months and it's some very clean and easy to understand code. Definitely a good influence.
I don't think you should treat unsafe code as that level of toxic. It's necessary when interfacing with with system APIs. The important part is that you try to have safe wrappers around the unsafe calls and that you document why the way you're using them is safe.
In addition to the points burntsushi gave in the sibling comment, I'd also add that keeping the standard library small and putting other well-scoped stuff like tegex, rand, etc. in dependencies also can reduce the burden of releases a lot. If some a bug gets found in a library that's not std, a new release can get pushed out pretty quickly. If a bug gets found in std, an entire new toolchain version needs to be published. That's not to say that this wouldn't be done for critical bugs, but when Rust already has releases on a six-week cadence, it's not crazy to try to reduce the need for additional releases on top of that.
This probably isn't as important as the stability concerns, but I think it still helps tilt the argument in favor of a small std at least a little.
One risk with a bigger standard library is that you'll do an imperfect job of it, then you'll be stuck maintaining it forever for compatibility reasons.
For example, Java developers can choose to represent time with Unix milliseconds, java.util.Date, java.util.Calendar, Joda-Time or java.time.Instant
It’s really just Date and Instant. Joda-Time isn’t part of the standard library. And if you’re listing Calendar, you might as well also list ZonedDateTime, OffsetDateTime, and LocalDateTime, not to mention stuff like java.sql.Date.
In reality, there’s just one old API and one new API, similar to the old collection classes (HashTable, Vector, etc.) and the newer JCF ones.
- backward compatbility: a big std lib increases the risk of incompatible changes and the cost of long term support
- pushing developers to be mindful of minimal systems: a sort of unrelated example is how a lot of node library use the 'fs' module just because it is there creating a huge pain point for browser bundling. If the stdlib did not have a fs module this would happen a lot less
- a desire to let the community work it out and decide the best API/implementations before blessing a specific library as Standard.
In my opinion a dynamic set of curated library with significantly shorted backward compatibility guarantees is the best of both worlds.
- less burden on the stdlib maintainers (which are already overworked!)
- faster iteration on those libraries, since you don't need to wait a new release of the compiler to get updates for those libraries (which would take at least 12-16 weeks depending on when the PR is merged)
A lot of people here are recommending WLED for the controller, but I would suggest you look at the Pixelblaze [1] instead. I've used both in a bunch of different projects and strongly prefer Pixelblaze over WLED.
Some reasons why:
- It has a much more intuitive user interface
- It's far easier to program new patterns. Programming is done in-browser with a language that's a subset of Javascript, with code changes being applied in realtime.
- Due to the way its rendering engine works, the patterns it produces are generally far more 'organic' looking and smoother than most of the WLED ones.
- It's possible to map LEDs in arbitrary 2D or 3D configurations (think lights strewn all over a Christmas tree), which WLED can't really do at all.
- If you have multiple Pixelblazes you can get them to sync with each other over Wifi.
- A really helpful community forum.
Downside:
- The firmware isn't open source, though some of its tooling is, and the firmware is stable and gets fairly regular updates, so it's not a huge issue to me. YMMV.
For the LEDs, you probably want wired bullet-style strings of LEDs rather than the thin copper LED strips since they're generally more suited to outside use. By far the most common (and generally cheapest) type of LEDs are WS-2812B or similar. They're OK, though you might notice they don't have good definition at low brightness levels. APA-102 or equivalent are a bit more expensive, but have MUCH better dynamic range, so I'd suggest going for these if you can. There are other better (and more expensive) LEDs still, but it starts to become diminishing returns, plus they can be hard to come by or find suitable controllers for. If you're running lengths of more than a 150 or so LEDs then power starts to matter, and you'll either need to inject power regularly into the strips, and/or use LEDs designed to take 12V or 24V. These can come with caveats such as worse power consumption and/or fewer addressable LEDs per meter, so research what you're buying carefully.
This gets such a huge thumbs up that I had to scroll up and reread it to make sure this wasn’t my own post from a revived thread from last year!
I’ve been using a pixelblaze with a long string of cheap 2812 LEDs on my Christmas tree for three years now with tons of compliments from neighbors.
I’m an embedded software guy, and every year I mean to dig in and try roll my own, or do something clever with an RP2040 board (also a shoutout for the Pimoroni Plasma), but the demands of life and “get the light show started” mean I keep using the Pixelblaze.
I even upgraded to their newer versions last year, and used some of the smaller ones to make some LED tutus for my girls that synced pattern with the tree (the tutus were synced with each other for a Christmas show, but it was trivial to then add the tree for fun afterwards).
The mapping is huge for the wow factor, and the pixelblaze makes it so much easier to get something fast and good enough.
There’s so many community-shared patterns to choose from, and it’s been easy to make small modifications to look better once mapped to a tree, though most work as-is.
My project I won’t get done this year is to try to make some calibration patterns and use ChatGPT to analyze some photos/videos to make a 3-D map, but I’ll realistically probably end up with the vaguely-triangular 2-D map again; I can get it done in about 30 minutes now.
The following is a couple years ago. I think last year I was up to 1100 LEDs and the mapping was a bit better, but I didn’t take good videos.
You don't need any third party tools for this any more, OCR is now built in to the Snipping Tool. Just press ctrl+shift+win+s, select the region of the screen you're interested in, then use the new "Copy all text" toolbar button. (Note that this is very new and might not be rolled out to everyone yet)
/s noted, and sure Oracle are litigious, but the GPL community version of GraalVM, plus "early adopter" enterprise version licence[0] seems farily clear, and reasonable - at least as far as Oracle are concerned?
"...Note that the licensing terms with GraalVM are different from those of OpenJDK. In the case of OpenJDK the risk you open yourself to is security compliance (which you might overcome using other means) in the case of GraalVM you are in violation of the license at the end of 4 years. Unlike security compliance however, you can purchase a license from Oracle and bring yourself into the legal all-clear..."
Just stick to the non-enterprise version. Also, a medium article is hardly the arbiter of truth (and it talks about the enterprise version that became free recently)
You can use the left/right arrow keys to step through the existing snapshots, and turn off the "Rotate globe" option in the settings to keep your view in one place.
I'm not sure if it's fair to give it buggy code, but I just changed set(b) to set(d) in the example, and it doesn't realise there's a problem: https://whatdoesthiscodedo.com/g/517c50a
