also, now with #gpt4o, latency is going to be critical if you’re doing streaming audio/video, so #python may start looking less appealing. what’s the new #LLM language? #rust? #go? #cpp? #fortran?
i predict that there’s always going to be strong advantages to using #python for #ai, but with streaming audio & video of #gpt4o, there’s not enough latency slack for python.
i think a framework will emerge, similar to pyspark, where you can write python code that gets compiled into a steaming plan, and executed as highly optimized low level #rust code with the possibility of python UDFs. i figure it’s still a couple of years from being really usable rn
I've been moving between neovim, helix (can't get over the slightly different mental model compared to vim), vscode, rustrover... Curious what others use.
I've been helping to investigate a few LLVM and Rust bugs recently, and I keep running into pet peeves with how these bugs are reported, so I'm going to put together some #RulesForBugFiling
I don't want to discourage anyone from filing a bug, please do! But... be aware with how you represent the issue that you're seeing.
I also know that there are folks on here who are vastly more knowledgeable than I am, so feel free to suggest corrections, perhaps by filing some sort of report...
If you're going to claim something is a security issue, please explain what the attacker has gained by exploiting the bug. That is, what they can now do they couldn't before.
The more specific you can be on when a regression occurred, the better. A range of versions is good, a single version is great, a single commit is amazing.
Tools like git bisect are really helpful for this.
Providing a standalone example that reproduces the issue so that someone else can do that work is also great, with the bonus that it can be added to the regression tests.
usually, it is used to define methods, but in function arguments, it serves as syntactic sugar so you don't have to name generic types... but in a return type, it has a meaning that is slightly different, and actually expresses a semantic not even vanilla haskell can represent!
basically, instead of being able to return any type implementing a trait, it states that it can return at least one type that implements a trait.
in haskell terminology, specifying a generic type parameter is "forall a", while returning an "impl" is "exists a".
Second #RustNL result: zlib-rs now works with no_std (on main)
most work was done by fellow unconf attendee Jonas Kruckenberg.
This ability is cool not only because zlib-rs can now be used on embedded devices, but also because it guarantees we don't sneakily use rust's allocator: allocation in the library should only happen through some function pointers that get passed in.
After 10 years of commercial experience in #cpp I think I’m ready for a new chapter. I have played around with #rust#golang#zig and #clojure but most job offers that I see are for people with at least X years of commercial experience in this exact languages. Do you have any hints how to approach this? I would think that my previous experience as a #software engineer would matter. Especially since I do not expect to move to another senior role, I’m checking junior positions too. #jobsearch
Is it not possible to use grave accents in rust proc-macros? When I do, I get an "unknown start of token" error, even though it /is/ the whole token. When taking a peek at the TokenStream given to the proc-macro function, the grave doesn't appear at all
Absolutely fascinating deep-dive into the core data structures the folks at Zed Industries use for their #Zed#editor!
"Currently there are over 20 uses of the SumTree in Zed. [...] The list of files in a project is a SumTree. The information returned by git blame is stored in a SumTree. Messages in the chat channel: SumTree. Diagnostics: SumTree."
With some help from bjorn3 this was reasonably straightforward. I think the PRs are good templates for of someone wanted to work on a real compiler and implement further SIMD functionality. This issue lists some missing intrinsics
I needed #Rust bindings for an app to interact with #feedbackd to submit #haptic feedback. Here's the generated bindings for libfeedback in case someone else needs it too:
Breakthrough: I wrote a program that prints a line of text!
So what's the point?
Program written in #rust, cross compiled on #debian, linked with #vlink to a TOS executable {on Windows), put into a disk image on debian and executed on a real ST via a #gotek floppy emulator with #flashfloppy firmware.
Preview of what I have been working on recently. The core of this crate is a mere two traits. The crate will ship with a number of parsers and combinators, none of which rely on anything not exposed to downstream users.
I've attached a real-world situation, taken verbatim from the test suite. Parsing integers isn't as efficient as it could be yet, as it's using a naïve method.
Parsing in general compiles to be extremely efficient, and using it is ergonomic.
Once again I get foiled by switching languages. :blobcatfacepalm2:
In Javascript, you have to compare strings with ===, not ==, or else you'll run into type coercion problems, because Javascript thinks 1 == "1" is a totally fine thing to be true. (it's not)
But in Kotlin, === compares identity not equality for strings. But in the JVM, string values are aggressively cached, so === actually does what you want most of the time. Unless your strings come from weird places, like JNI code. Then you get awful non-deterministic behavior that's incredibly hard to debug, but it totally goes away when you use the correct comparison operator == for strings.
sigh I'm not really as good at this whole programming thing as I should be by now.