391–400 of 736 posts
Earlier quoted context omitted.
Linux kernel has support for rust userland drivers, and rust interops with python with pyo3.
Not sure what you mean by "userland" drivers here, but support for kernel modules written in rust is actively being developed. It's already being used for kernel drivers like the Asahi Linux GPU driver for M1 Macs.
https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.h...
Some days I have misgivings, but not about the language. About the crate situation. Too many important low-level crates stuck at 0.x. I've previously written about problems with the high-performance 3D graphics libraries, but only game devs care about those. At the language level, the big problem is back references. Sometimes you do need them, and the only safe way to do them at present involves reference counts in t…
> Too many important low-level crates stuck at 0.x. Is it fair to say that Rust failed to supply a robust set of standard libraries comparable to other modern languages? Or was the language aimed at level geared towards implementing rather than providing libraries? If it's truly a systems language, then what library features are essential, and what are 'nice to have'?
But it’s a trade off because there are concrete upsides to a large standard library. I wrote about this more - Rust has a small standard library (and that’s ok) - https://blog.nindalf.com/posts/rust-stdlib/
Perhaps my biggest critique is that crates.io has no namespacing. Anyone can just claim a global and generic package name and we mostly have to deal with it (unless you avoid using the crates.io repository, but then you'll probably have more problems...). Some of these globally-claimed generic packages are not really the best package to use. Maybe it was a reaction against the Java-style reverse DNS notation, which i…
I did some analysis on crates.io to find the top name squatters. Then I did some calculations and found that the top name squatter created their crates at a rate of about one ever 30 seconds for a period of a week straight. I send the analysis to the crates.io team and pointed that they have a no-automation policy. They told me that it was not sufficient proof that someone was squatting those names. That's my problem…
Some days I have misgivings, but not about the language. About the crate situation. Too many important low-level crates stuck at 0.x. I've previously written about problems with the high-performance 3D graphics libraries, but only game devs care about those. At the language level, the big problem is back references. Sometimes you do need them, and the only safe way to do them at present involves reference counts in t…
> Too many important low-level crates stuck at 0.x. Is it fair to say that Rust failed to supply a robust set of standard libraries comparable to other modern languages? Or was the language aimed at level geared towards implementing rather than providing libraries? If it's truly a systems language, then what library features are essential, and what are 'nice to have'?
They often have better quality than what I find in "mature" packages in npm or PyPi.
Rust kind of has a perfectionist touch to it which makes it really hard to say "this public API is stable". So people stay at 0.. way longer than normal.
I'm fine with that.
The lack of namespacing and heavy namesquatting is rather what's annoying.
Some days I have misgivings, but not about the language. About the crate situation. Too many important low-level crates stuck at 0.x. I've previously written about problems with the high-performance 3D graphics libraries, but only game devs care about those. At the language level, the big problem is back references. Sometimes you do need them, and the only safe way to do them at present involves reference counts in t…
Out of curiosity, is there any existing language (including research languages) that can do this already?
Earlier quoted context omitted.
It interops seamlessly with C libraries.
Depending on what seamlessly means, Rust can also interop with C libraries. I wrapped a bunch of them.
Earlier quoted context omitted.
> but the ergonomic is really bad. Every time I write some rust I feel limited. > But I do not think it is a good general purpose language. Remember that this is not a sentiment that's shared by everyone. I use Rust for tasks that need anything more complicated than a shell script. Even my window manager is controlled from a Rust program. I say this as someone who has been programming in Python for nearly two decades…
I've finally set my mind to properly learning a new language after Python, Haskell, and typescript. I'm looking into Rust especially because of how I've heard it interoperates with Python (and also because it's maybe being used in the Linux kernel? Is that correct?).
And yes the Python interop is excellent.
I wrote a lot of rust, but after some years it still feels unproductive. I do a lot of zig now and I am like 10 times more productive with it. I can just concentrate on what I want to code and I never have to wonder what tool or what library to use. I know rust gives memory safety and how important that is, but the ergonomic is really bad. Every time I write some rust I feel limited. I always have to search libraries…
IMO a good GPR is memory safe (no C, C++, Zig), is easy to use(no Rust), has strong static typing (no Perl, Python, Ruby) and is "stable" (no Scala). Lots of choices remain: Java, Kotlin, Ada, D, OCaml..
I wrote a lot of rust, but after some years it still feels unproductive. I do a lot of zig now and I am like 10 times more productive with it. I can just concentrate on what I want to code and I never have to wonder what tool or what library to use. I know rust gives memory safety and how important that is, but the ergonomic is really bad. Every time I write some rust I feel limited. I always have to search libraries…
Given that Zig is memory unsafe it isn't either a good general purpose language. IMO a good GPR is memory safe (no C, C++, Zig), is easy to use(no Rust), has strong static typing (no Perl, Python, Ruby) and is "stable" (no Scala). Lots of choices remain: Java, Kotlin, Ada, D, OCaml..