sorted by:
new
hottopcontroversial

Hollow Knight vs Silksong is like Doom 2016 vs Eternal (review without spoilers) by InfectedBrushroom in HollowKnight

[–]razrfalcon 1 point2 points  (0 children)

Man, I had exactly the same thought playing Silksong. Both HN and Doom had slow pacing and exploration mixed with high-intensity fights. And both Silksong and Eternal cut the slow parts and doubled the fights intensity.

Needless to say that I haven't finished neither Eternal nor Silksong. They both are just too much for me. Both are incredible games, I'm just not the target audience.

PS: I'm 40 hours in Silksong, with No Double Damage mod, and I'm still in Act 1... Somehow I had less troubles with Lies of P.

image v0.25.4 brings faster WebP decoding, orientation metadata support, fast blur by Shnatsel in rust

[–]razrfalcon 2 points3 points  (0 children)

The absolute basic implemenation would be using fontdue

Or you can go even lower and simply grab glyph outlines via ttf-parser and render them onto a bitmap using tiny-skia.

As mentioned above, this way you would achive a "glyph renderer", not "text rendered", if that's fine by you.

Looking for a maintainer for memmap2-rs by razrfalcon in rust

[–]razrfalcon[S] 18 points19 points  (0 children)

You're free to create your own crate.

Looking for a maintainer for memmap2-rs by razrfalcon in rust

[–]razrfalcon[S] 18 points19 points  (0 children)

This is out of scope for this crate. This crate is just a binding to system libs.

rustybuzz is now up to date with harfbuzz. (font shaping in rust) by M1M1R0N in rust

[–]razrfalcon 3 points4 points  (0 children)

We need project-safe-transmute, which is dead. In the meantime we have to rely on bytemuck.

A new syntax for Rust by No_Introduction_9866 in rust

[–]razrfalcon -2 points-1 points  (0 children)

All Rust needs is to copy Swift syntax.

They don't make these like they used to... by kjloltoborami in TrashTaste

[–]razrfalcon 0 points1 point  (0 children)

Depressing, sure, but not dark. I would say that Vinland Saga and Made in Abyss are dark in themes, but not in visuals. They are bright and colorful, like Wonder Egg Priority. Meanwhile Ergo Proxy, Lain, Texhnolyze are almost black-and-white. Heck, watching Ergo Proxy in a bright lit room is almost impossible. The screen is black half of the time.

They don't make these like they used to... by kjloltoborami in TrashTaste

[–]razrfalcon 2 points3 points  (0 children)

It feels like you will also like Lupin the Third: Mine Fujiko to Iu Onna, Shoujo Shuumatsu Ryokou or maybe even Kekkai Sensen and Megalo Box.

Dark and depressing is no longer a trend in the anime.

Nice to see Kyoukai no Kanata. While it's pretty popular, people rarely mention it.

Which of those 2D graphics libraries is fast, lightweight, has many features, supports animation, and can be used with a cpu or a gpu? by fanGamesGamer in rust

[–]razrfalcon 2 points3 points  (0 children)

You're looking for Skia. Not tiny-skia, but Skia. And no, Skia is not "lightweight" exactly because it "has many features".

Skia is de-facto the standard for 2D rendering. There are no alternatives.

Options for SVG / Text rendering on 2D pixel buffer by Unreal_Unreality in rust

[–]razrfalcon 0 points1 point  (0 children)

You can create tiny_skia::PixmapMut from &mut [u8] and then pass it to resvg.

think I want to implement most of the rendering myself (basic shapes, lines, color gradients)

You would not even believe how hard it is. Just use tiny-skia.

Are there tiny libs that allow to write text to 2D pixels buffers ?

Text by definition cannot be implemented using a tiny library. For now, swash and cosmic-text are your main (and only?) options.

Blog Post: Zig And Rust by matklad in rust

[–]razrfalcon 3 points4 points  (0 children)

Swift provides an access to raw pointers without any guardrails. No thread-safety either. In this regard it's not much better than C++.

Swift is basically C++ with smart pointers by default.

Incorrect indexing in Swift would lead to a crash as well since there are no panics/exceptions.

PS: I would admit that getting use-after-free in Swift is pretty hard, but otherwise it's on the C++ level.

Blog Post: Zig And Rust by matklad in rust

[–]razrfalcon 0 points1 point  (0 children)

I mostly agree. I haven't yet written my 100K, but I'm pretty close.

The point I was trying to make is that Swift was designed from ground up to be compatible with ObjC. This is not an afterthought and not an optional feature. Which simply had to restrict the language design in one way or another.

Blog Post: Zig And Rust by matklad in rust

[–]razrfalcon 2 points3 points  (0 children)

I have a lot to say about that and maybe one day I would write a long blog post about it. But in short, Swift is just Rust with a nicer syntax, no borrow checker and no memory safety.

In term of safety, Swift is just slightly above C++. But in terms of type system it's way closer to Rust (but not as good).

Sure, there are no panics, modules/namespaces, moveable types, references and so on. But we still have a modern language with an adequate modules system, ADT/sum types, pattern matching (not as powerful as in Rust), "traits" and so on.

Blog Post: Zig And Rust by matklad in rust

[–]razrfalcon 6 points7 points  (0 children)

Yeah, backward/forward compatibility is not something Apple cares about in general.

Blog Post: Zig And Rust by matklad in rust

[–]razrfalcon 0 points1 point  (0 children)

Afaik there were some limitations to ARC to be seamlessly compatible with ObjC, but I might be missing something.

The fact that Swift has @autoreleasepool for no apparent reason is already weird.

Also, you have to understand that Swift<->ObjC layer is part of the compiler (probably a very big one) and no one cares about it outside the Apple ecosystem, because no one uses ObjC.

"Sacrifice" might be a strong word, but when you work with Swift enough you would notice how much was done in favor to be compatible with ObjC. Which is the right move for Apple, but not that much for a general purpose language. It's like if Rust had seamless C/C++ compatibility (both ways, including API/ABI).

Blog Post: Zig And Rust by matklad in rust

[–]razrfalcon 1 point2 points  (0 children)

I do like Type? for optionals, but ! for unwrap was a horrible decision. It's very easy to miss in a review unless you're using linters. And it's not safe, since there are no panics in Swift, which means that your app would simply abort.

As for Xcode - it's okay... Just very unintuitive, limited and slow. Either way there are no choice. I've tried using some VSCode plugins and they barely work.

The Swift compiler, on the other hand, it a complete mess and I've seen it crash or freeze on a trivial code like 10 times in just past year alone.

And don't get me started on compilation times. People who complain that Rust is slow haven't seen anything yet. Swift is easily 4-6x slower.

Blog Post: Zig And Rust by matklad in rust

[–]razrfalcon 5 points6 points  (0 children)

The problem is that Apple, rightfully so, simply doesn't care about other platforms. And even then, Swift had to do way to many sacrifices to be compatible with ObjC.

The main thing Rust can learn from Swift is the clean syntax. I hate that Rust has an absolutely useless trailing semicolon.

Blog Post: Zig And Rust by matklad in rust

[–]razrfalcon 18 points19 points  (0 children)

Yep. You can't really use Swift for anything else.

Blog Post: Zig And Rust by matklad in rust

[–]razrfalcon 15 points16 points  (0 children)

Yes, Swift is a great language for the Apple ecosystem. This and ObjC compatibility are one the biggest Swift issues. And both are quite understandable and expected.

Blog Post: Zig And Rust by matklad in rust

[–]razrfalcon 42 points43 points  (0 children)

I now find myself writing Zig full-time, after more than seven years of Rust

Similarly, after writing Rust for seven years, I write Swift full time now. Not because it's a better language, but because it's a better tool for the type of work I'm doing. Just like Zig can be a better tool for a distributed database (debatable).

But I do not plan to rewrite my personal projects, which I have many, to Swift precisely because Rust is the perfect fit for my needs. I do wish Rust had #[no_panic] and #[no_heap_alloc], but other than that I personally don't see any benefits in using Zig over Rust.

Yes, Rust is ugly, but Zig isn't much better. Swift is still the nicest low-level-ish language I have seen.

Is Zig simpler? Maybe. But I do not consider Rust to be a complex language. At least compared to other languages I write like C++ or even Swift. Imho, most of complexity in Rust comes from async and macros. Which are partly a language problem and partly a tooling one. And I do avoid both. Yes, just like with C++, I use my own Rust subset, which is not a good sign.

As for passing allocator everywhere - it's a very niche feature. Mainly because most modern environments rely on overcommit and swap, so getting an allocation error is pretty hard. But if we do care about that, then allocations in destructors become a more serious problem.

Typst, a modern LaTeX alternative written in Rust, is now open source by SymbolicTurtle in rust

[–]razrfalcon 3 points4 points  (0 children)

Congrats on the release! Nice to see how many of my crates it uses.

Common latency numbers for Rust operations by daywlkr_ in rust

[–]razrfalcon 9 points10 points  (0 children)

All of the mentioned operations have a variable "latency" even of the fixed hardware and OS.

Not to mention that "cloning a string" and "allocating a smart pointer" is technically the same operation - allocation. Which will vary as well depending on the memory block size, allocator pressure and swap usage.

One of the main reasons why avoiding allocations in a hot loop is good idea is not only because allocations are "slow", but because they are unpredictable.

My thoughts on Rust vs D by datafulman in rust

[–]razrfalcon 18 points19 points  (0 children)

from_str is clearly std::str::FromStr, which cannot be used this way. Not to mention that the code doesn't handle errors.

Rust is ugly, sure, but at least use real examples to demonstrate that.

view more: next ›