Hacker Newsnew | past | comments | ask | show | jobs | submit | skavi's commentslogin

Disclaimer: I don't really use Zig (primarily a Rust dev) but I do think it's quite cool.

If you're willing to dive right into it, I'd first read a bit about the comptime system [0] then have a go at reading the source for `MultiArrayList` [1], a container which internally stores elements in SoA format.

At least, that was what got me interested.

[0]: https://ziglang.org/documentation/master/#comptime

[1]: https://codeberg.org/ziglang/zig/src/branch/master/lib/std/m...


I am going to ask a question that is is definitely not the place for, but I am not involved with Zig in any way and am curious, so I hope you'll indulge me.

I noticed the following comment was added to lib/std/multi_array_list.zig [0] with this change:

        /// This pointer is always aligned to the boundary `sizes.big_align`; this is not specified
        /// in the type to avoid `MultiArrayList(T)` depending on the alignment of `T` because this
        /// can lead to dependency loops. See `allocatedBytes` which `@alignCast`s this pointer to
        /// the correct type.
How could relying on `@alignOf(T)` in the definition of `MultiArrayList(T)` cause a loop? Even with `T` itself being a MultiArrayList, surely that is a fully distinct, monomorphized type? I expect I am missing something obvious.

[0]: https://codeberg.org/ziglang/zig/pulls/31403/files#diff-a6fc...


I had to search for this, but managed to find the relevant mlugg@ comment[0] on the ZSF zulip:

> i had to change the bytes field from [*]align(@alignOf(T)) u8 to just [*]u8 (and cast the alignment back in the like one place that field is accessed). this wasn't necessary for MultiArrayList in and of itself, but it was necessary for embedding a MultiArrayList(T) inside of T without a dependency loop, like

    const T = struct {
        children: MultiArrayList(T),
    };
    // reproduced for completeness:
    fn MultiArrayList(comptime T: type) type {
        return struct {
            bytes: [*]align(@alignOf(T)) u8,
            // ...
        };
    }
[0]: https://zsf.zulipchat.com/#narrow/channel/454360-compiler/to...

Ah, that makes sense. Thanks for pulling this up!

He went into it a bit more over on Ziggit today too. I only noticed it way after I went digging: https://ziggit.dev/t/devlog-type-resolution-redesign-with-la...

blends

Since Geekbench 5, the single threaded benchmark scores have aligned pretty well with those from the industry standard SPEC benchmark.

thank you. TFA is just an awful read.

I’m curious what issues people were running into with Swift’s built in C++ interop? I haven’t had the chance to use it myself, but it seemed reasonable to me at a surface level.


There's a list of unsolved problems in this Ladybird issue, now closed because they dropped Swift: https://github.com/LadybirdBrowser/ladybird/issues/933

for example: "Swift fails to import clang modules with #include <math.h> with libstdc++-15 installed. Workaround: None (!!)"


Just yesterday someone was telling me xmake does a lot of what bazel can do (hermetic, deterministic, optionally remote builds) while being easier to use.

I took a look at the docs later and couldn’t find a direct comparison. But there does seem to be a remote build system. And there were a few mentions of sandboxing.

Can anyone provide a head to head comparison?

Does xmake strictly enforce declared dependencies? Do actions run in their own sandboxes?

Can you define a target whose dependency tree is multi language, multi toolchain, multi target platform and which is built across multiple remote execution servers?


These guys aren’t going to use L4T. ACPI compliant, standard GPU drivers. They’ve also upstreamed a lot of the L4T patches.

See DGX Spark.


In Nix (and, I’d assume, for Guix) you can go the other way around: https://mitchellh.com/writing/nix-with-dockerfiles.

As a side benefit, the generated docker image can be very tiny.


Yeah Guix has a Dockerfile export


Dunno about Skip, but I can always tell when an app is Flutter. They feel like crap. Everything's a bit off with the native looking widgets. And fully custom designs still animate a bit weirdly. And they definitely still stutter. Somehow a tier below React Native.


Flutter re-generates the entire layout every tick and diffs it (immediate-mode), like a game engine. If your device isn't quite fast enough it'll lag, yep. RN is retained mode (but written in immediate-mode style and the diffing only happens when it has to).


That is absolutely not true. Elements with dirty layouts are tracked and layout is only recomputed up to the neearest layout boundary.


Weird, it looks like you're right but I recall their early marketing saying stuff like just rebuild the whole layout, it's cheap since it's compiled. They must have meant it's cheap to rebuild as needed haha


I'd say it's the opposite, on crappy devices, Flutter feels faster than native, not sure how but that's the end result. I've been testing on an old Samsung J3 and it's definitely better than native.

That's also maybe why it's so popular in India.


Flutter is essentially a game engine so it bypasses the typical cycles involved with native widgets and there are several different ways why Flutter works well on lower end phones


Interesting, I didn’t know that it was immediate mode. According to the article [1] though, it now uses rendering engine with Retained Mode due to performance issues.

[1] https://medium.com/@0s.and.1s/flutter-part-iv-skia-vs-impell...


ah neat, so they rewrote the rendering engine in C++ and exposed it via Dart APIs, as opposed to everything being in Dart.


It has been like that since the very beginning (sky engine).


I've noticed several of the apps that don't respect device animation settings were built with Flutter. Not sure if that's a limitation of it or if the developers culturally don't bother.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: