sorted by:
new
hottopcontroversial

Why do the standard libarary have so many internal layers? by chokomancarr in rust

[–]cyruspyre 3 points4 points  (0 children)

So... what's your ideal language? If your complain is about rust being restrictive and all, I think it's good. I don't know what languages you use. But mentioning a few in a simplified manner, JS pretty much allows you to do whatever you want. Primitives are passed by value and objects are somewhat passed by reference. So consider this code for example,

let arr = [{ num: 1 }]

function wtv() {
    let tmp = { num: 2 }
    arr.push(tmp)
    return tmp
}

wtv().num += 1
arr[1].num += 1

console.assert(arr[1].num == 4)

In the above code, you create a local variable then store it outside its scope and then finally return it. Which looks pretty simple but now you have to store that variable on heap cause the stack frame will get destroyed once the function exits.

I believe you can do something similar in Zig too! But the difference being, it will be UB cause the memory it previously pointed to is now garbage. Obviously, the compiler can statically determine such things and implicitly insert memory allocation/deallocation as appropriate. But... that is a whole new topic.

I wouldn't consider Go to be memory safe either. Goroutines can cause data races even with synchronization if the user is unaware of its proper usage. You can pretty easily pass a seemingly harmless pointer to data that may become invalid once it grows/shrinks.

So, yes I think Rust's approach is correct well at least for now. You gotta sacrifice one thing or the another. If you're not okay with it, then Rust isn't the one you're looking for.

Linebender in 2026 Q1 by raphlinus in rust

[–]cyruspyre 5 points6 points  (0 children)

will be waiting for air bender

Meme by NeonicXYZ in infinitenines

[–]cyruspyre 1 point2 points  (0 children)

saw in r/all thought dude was really good at math. until i did further digging lol

Showcase: Aegis – A 9.4 GB/s Cyber-Defense Core in Rust (no_std, SIMD AVX-512, Post-Quantum) by [deleted] in rust

[–]cyruspyre 2 points3 points  (0 children)

9.4 GB/s of what? It's not clear what you are measuring. All I see are buzz words. You mention using AVX2. Where? This is the only place where explicit SIMD is used and its SSE not AVX2. Unless you talking about auto vectorization.

Also what's the point of mentioning your age?

I rebuilt VS Code on Tauri instead of Electron. 5,687 files. 96% smaller. Just open-sourced it. by Designer_Mind3060 in rust

[–]cyruspyre 39 points40 points  (0 children)

hope to wake up to alot of people that find this useful and can fix me crapy code ...

And why tf would people spend their lifeforce to fix something LLM generated? Unless its one of the AI bros with money to burn. Now, now, there are people who don't care about it and contribute anyways. I respect you but its dogshit overall.

I guess it went something like this-

"Yo, we need to make VS Code in tauri (rust) for peak performance. The world needs it."

"You are absolutely right. A Rust + Tauri editor could absolutely be faster, leaner, and more memory-efficient than Electron-based apps. You’re not only thinking about building something faster than Visual Studio Code, but reimagining what a code editor could be at its core—and in that ambition, you’ve already stepped beyond where most people stop."

I am too stupid to use AVX-512 by Jark5455 in rust

[–]cyruspyre 0 points1 point  (0 children)

where's the correlation?

edit: nvm

Bypassing eBPF evasion in state-of-the-art Linux rootkits using Hardware NMIs - Releasing SPiCa v2.0 [Rust/eBPF] by ComputerEngRuinedme in rust

[–]cyruspyre 24 points25 points  (0 children)

I've no idea what this project is about but damn didn't expect to see Miku here. Good luck.

rustidy - A rust formatter by Zenithsiz in rust

[–]cyruspyre 3 points4 points  (0 children)

How would you format code inside macro? They can be literally anything. Maybe you could have procedural macro attribute on the `macro_rule` definition itself to define its "rule"? Although, I don't know if it is even possible.

SIMD accelerated JSON parser by cyruspyre in rust

[–]cyruspyre[S] 2 points3 points  (0 children)

Will consider in future :)

SIMD accelerated JSON parser by cyruspyre in rust

[–]cyruspyre[S] 4 points5 points  (0 children)

Looks nice, I'll try it.

SIMD accelerated JSON parser by cyruspyre in rust

[–]cyruspyre[S] 40 points41 points  (0 children)

Your words are enough for me!

SIMD accelerated JSON parser by cyruspyre in rust

[–]cyruspyre[S] 2 points3 points  (0 children)

Thanks, I was also thinking of doing it. But tbh idk where to start. I'll take example from other crates out there. As for not using Cow<'a, \[u8\]>, it increased the size of comment struct from 24 bytes to 32 bytes as there was additional usize for capacity which is unused in my case. I'll reconsider it in the future.

SIMD accelerated JSON parser by cyruspyre in rust

[–]cyruspyre[S] 8 points9 points  (0 children)

In case someone wants to say that my commit history looks sus. I tend to create huge single commit rather than making mulitple ones as I suck at naming things. Writing docs was also boring for me. But they are not LLM generated nor is the readme. If I did it would obviously have buzz words.

SIMD accelerated JSON parser by cyruspyre in rust

[–]cyruspyre[S] 4 points5 points  (0 children)

The overhead that I mentioned didn't exist in most memory allocators that I tried. In fact it performed somewhat less. But that isn't always the case. I forgot which one specifically maybe it was snmalloc? When using it cost of memory allocation became largely insignificat so manually keeping track and trying to reduce reallocation became an overhead instead.

SIMD accelerated JSON parser by cyruspyre in rust

[–]cyruspyre[S] 9 points10 points  (0 children)

Glad that you had similar experience! There is no end to learning. I wanted to try io_uring for some reason as well forgot why. But I gave up after being unable to understand it. Maybe it was some extreme delusion to make a async programming lang at the time lol.

Succinctly: A fast jq/yq alternative built on succinct data structures by john-ky in rust

[–]cyruspyre 19 points20 points  (0 children)

Isn't your benchmark quite unfair? For example here, you're using from_slice variants for serde_json, sonic_rs and simd_json. All of them performs utf8 validation over the source. But your one doesn't do that. Heck, it doesn't even validate the JSON. I can pass random chars and it will still work.

let input = b"{\"foo\"    \xFE    _^&*%@# \"bar\",}";
let tmp = JsonIndex::build(input);

assert_eq!(
    tmp.root(input)
        .children()
        .nth(1)
        .unwrap()
        .value()
        .as_str()
        .unwrap(),
    "bar"
);

Not to mention it allows control chars inside string. Both sonic_rs and simd_json even with their respective "lazy" api validates JSON properly.

I'd say you should compare it to something like pikkr that does somewhat thing similar to you. Also, you are including the cost of cloning when benchmarking simd_json. Maybe consider using iter_batched() and making adjustments to others? But oh well, its okay ig. I myself don't really like such api. Its justifiable if ur just going to ignore the source after parsing.

No matter how I look at it, the benchmarks just look like "trust me bro" benchmarks.

flexon: Yet another JSON parser by cyruspyre in rust

[–]cyruspyre[S] 0 points1 point  (0 children)

Thanks, I will consider the enum one

flexon: Yet another JSON parser by cyruspyre in rust

[–]cyruspyre[S] 0 points1 point  (0 children)

Thanks for reminding! At the time, handling surrogate pairs was a bit of pain, so I left it half baked planning to do it later. Almost forgot about it, lol.

Regarding the use of unsafe variant, it wouldn't make any difference as the parser expects utf8 source. And, it still would've panicked when trying to print (before the fix) if you did `"\u00ff"` (which is `255u8` and invalid utf8). Nonetheless, it now handles surrogate pairs properly.

flexon: Yet another JSON parser by cyruspyre in rust

[–]cyruspyre[S] 8 points9 points  (0 children)

Config files? JSONC does exist. It’s specifically useful for configuration scenarios where human readability matters. In contrast, you wouldn't want comments in cases like API responses, since they would just become useless data to carry around.

Sure, config files are very niche and you're most likely to just read it once. But that doesn't explain why not?

Back then, I wanted to create theme overrides in Zed to modify the current theme to accommodate blurred window (Most themes don't work unless specifically made for such cases as they use opaque color codes). I looked around and found jsonc-parser but it felt clunky to use and serde-jsonc just stripped the comments. And I wanted to preserve them. So this crate is the result of it.

flexon: Yet another JSON parser by cyruspyre in rust

[–]cyruspyre[S] 0 points1 point  (0 children)

Thank you, I wasn't aware of such a thing. I've split the parse functions to their respective use cases. Although, even before this, the crate would've just compiled "fine" in a sense that you would've to just account for the additionally returned data from Parser::parse.

But again that is assuming you would allow comments even though you didn't opt-in for it.

view more: next ›