Really nice little tool, this is indeed surprising how little code is needed for something like this. Treesitter is definitely a huge help there.
Very nice milestone and interesting tech for sure. Congrats to them!
This is an interesting move. There are good reasons for it in this article. Also some I'm less inclined to take at face value but still, worth keeping in mind.
Nice walk through for a use of PyO3 to make some Python code much faster. Nice to see how useful py-spy turn out to be in such scenarii as well.
People tend to be fixated on the "unsafe" keyword and assuming not using it will make their code devoid of memory safety bugs. Well, it's a bit more subtle than this. It helps you know where such bugs can hide but it can't completely prevent them all the way down the stack.
Not earth shattering benchmark, kind of confirms what we can expect on the concurrency and REST side of things: Rust, Go > .NET > JVM
That's an interesting perspective. Rust definitely gets in the way of iterating quickly indeed which might be a problem to test ideas. Introducing it gradually later is thus a better path. That being said it doesn't always have a great story for mixing with other languages, there are a few tools to help, but nothing I've seen really used in the wild so far (this will probably come though).
Looks like an interesting runtime. Seems to make it easy to create multiplayer 3D experiences. Maybe too easy to be true? I guess I need to find an excuse to test it.
It's good to also see articles which point out the problems with Rust. Overall I find it an interesting language but people tend to oversell it too much. This is a nice reminder it already carries complexity issues.
Oh, that looks very interesting. I'd definitely have use for this. I tend to manage several aws or ssh configs per customers and it's not always easy to deal with. This could lead to a nice separation.
Looks like an interesting (even though young) tool to make your own linters and to analyze code source.
Like it or not, this is definitely filling a very unique niche. It's a very good fit for system software where safety is important and available time limited. There is no better option for now.
Looks like an interesting frontend stack. Still young but probably worth keeping an eye on.
Undefined behavior do exist and well... they're really undefined, don't make any assumption about them.
Don't believe claims about Rust (or any other options in fact) being a language for universal use. It has a few spaces where it shines and others where it'll be a drag. Picking the right language and stack is a multi-factor decision process where the technical advantages of the language itself say less than half of the story.
Very good overview about RAII, ownership, borrowing references. All that comparing C++ and Rust in their ways to handle those concepts. Definitely a must-read even though it's a bit long.
Always interesting when a language influence the use of another one. I like this kind of epiphanies.
This is definitely a big deal both for the kernel and for Rust.
This should hopefully ease the pain of mixing Rust with other languages.
Interesting interview about some serious usage of Rust in the embedded space. That's where I'd expect it to shine.
Interesting set of challenges indeed. I think Rust is a bit at a crossroad now. The next few years will be crucial, either they will lead to further adoption or it will stagnate and slowly disappear.
Interesting points in there, indeed we rarely see things presented along an advantage in productivity for Rust when it's compared to Python.
In the end, this is a nice conversation about language design...
Polars looks like an interesting alternative to Pandas in the industrialization phase of a data processing pipeline. The performance difference are really notable with larger volumes. I'd be interested to see how much of it is lost when using its Python API though.
Interesting forensic of a supply chain attack targetting crates.io. Especially fascinating to me is how it then tries to target CI build environments as preparation for larger attacks.
Interesting balanced view about Rust. Looks like it highlights strengths and weaknesses properly.
I like it when type systems can express this kind of constraints. It clearly allows to catch mistakes early in the development cycle.
This is in part a rant but lots of points in there are very valid. This is in part why I don't find Go a very compelling option so far. Modern tooling indeed, nice runtime in some areas but leaves way too much of the complexity in imperative code.
Looks like it's still in the very early days but the overall approach looks interesting.
Interesting use of Rust behind a Python API. This is IMO an interesting niche for the language.
Interesting and fair list of pain points around Rust. This is a change from the pure fan boy articles we see most times.
Interesting use of WebAssembly for fast and very portable code. Also especially interesting is the care in the move to the new software architecture.
Interesting example of using a strong type system to avoid mistakes in code using a parsing and serialization library. The fact that it's about IMAP and I'm still traumatized by it has nothing to do with my interest in that article, really.
This is good to see this is still making progress.
This is a good highlight of the differences. It's not "one is best", it is really "pick what is best in your context".
Sounds like a potentially interesting tool especially combined with curl.
Nice description of the community management in the Rust community.
The journey of Rust inside of the Linux kernel is still in its early days. I find especially interesting the questions raised by the community. It's especially healthy in my opinion, it's not just "fancy let's have it". They also wonder about the learning path for people to join the community if it's accepted or where to best use it. It's a good account of the social aspects triggered by technical changes.
Nice comprehensive list of the smart pointer types in Rust.
This is Rust focused but still, shows a good way to increase binary portability across distributions. I suspect a couple of things would be easier with elf-dissector even.
The use of PyO3 keeps being very interesting for Rust / Python interoperability. The porting experiment in this article is well done and shows well the strength and weaknesses of both.
Interesting use of Rust to optimize an otherwise completely Python base code. This is properly done, first profiling the problematic system finding where the bottleneck is, evaluating other options first, then finally biting the bullet. Leads to a dramatic improvement by just replacing a few lines of Python. This is far from the "let's rewrite everything in Rust" which is a good thing.
Interesting take, it's a bit what I feel coming from C++ and keeping an eye on Rust, it's accumulating features fast and there's a risk of things becoming inconsistent.
Still keeping an eye on what's available for crunching numbers in Rust. Apache Arrow looks like an interesting option.
I like when papers aren't about "mine is better than your". This is an interestingly balanced take on those two popular option showing where they fit best. Shows good reasons for a polyglot approach: as usual use the best tool for the job.
Somehow states the obvious: you don't always need docker. Still a good reminder, especially true with the trend of single binary web services like what can be achieved with Go and Rust.
Ah, finally looks like we got an interesting dataframe crate in the Rust world. Performances seems nice too.
To be seen how it behaves in practice. The explanations of how it's designed are interesting in any case. :-)
Interesting conversation of the growing pains around the introduction of async/await in Rust.
Interesting comparison even though the conclusion is slightly unsurprising: Pandas is slower but more convenient, Rust is fast, consumes less memory but more work is involved. At least this gives a few indications on what type of APIs could be added to Rust to ease some things. It also indicates that Pandas can be great to develop the pipeline with then a switch to Rust when this needs to be optimized for higher volumes of data.
Still a young project but that looks like an interesting approach. At least it would make for much smaller bundles than Electron while still enabling the same type of uses. I still have slight concerns about the complexity involved because of all the layers or how much memory this can consume (akin to Electron). Let's wait and see how it evolves.