Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Assorted Thoughts on Zig and Rust

scattered-thoughts.net

Post reply on HN
Print view View original

231–240 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#231

Post by Rusky »

jcelerier wrote: post #230
Rusky wrote: post #207

Earlier quoted context omitted.

It carefully designs its name mangling such that this doesn't happen in the first place, even in the presence of multiple slightly-different builds of a library. The only way to get matching names is to ask for them explicitly, via FFI.

> It carefully designs its name mangling such that this doesn't happen in the first place, even in the presence of multiple slightly-different builds of a library. but, after checking apparently this adds a hash of the function to the name mangling - how does that work when you want to call it from another language ? e.g. for instance you can call C++ code directly through some dialects of Lisp, Perl , ADA, or D (AFA…

If you want to call Rust code from another language, you use its FFI tools to export an un-mangled API. This is typical for C++ as well- trying to interop with mangled C++ names requires a lot of coordination across the toolchains and so even the examples you cite don't work without a lot of pain.

If you do wind up exporting the same name twice, you just get a linker error, because Rust doesn't play the same games C++ does with linkage. (This is also true of C++ FFI- the problematic ODR-violation stuff tends to involve more complex language features than `extern "C"`.)

Re: Assorted Thoughts on Zig and Rust

#232

Post by jcelerier »

jcelerier wrote: post #230
Rusky wrote: post #207

Earlier quoted context omitted.

It carefully designs its name mangling such that this doesn't happen in the first place, even in the presence of multiple slightly-different builds of a library. The only way to get matching names is to ask for them explicitly, via FFI.

> It carefully designs its name mangling such that this doesn't happen in the first place, even in the presence of multiple slightly-different builds of a library. but, after checking apparently this adds a hash of the function to the name mangling - how does that work when you want to call it from another language ? e.g. for instance you can call C++ code directly through some dialects of Lisp, Perl , ADA, or D (AFA…

carefully designed LOL what kind of joke is this

    $ echo "pub fn my_function() -> i32 { 0 }" > bar.rs ; rustc --crate-type=dylib bar.rs && nm -A libbar.so| grep my_fun
    _ZN3bar11my_function17hce21faeb92ac13c6E

    $ echo "pub fn my_function() -> i32 { 1 }" > bar.rs ; rustc --crate-type=dylib bar.rs && nm -A libbar.so| grep my_fun
    _ZN3bar11my_function17hce21faeb92ac13c6E

Re: Assorted Thoughts on Zig and Rust

#233

Post by jcelerier »

Rusky wrote: post #231
jcelerier wrote: post #230

Earlier quoted context omitted.

> It carefully designs its name mangling such that this doesn't happen in the first place, even in the presence of multiple slightly-different builds of a library. but, after checking apparently this adds a hash of the function to the name mangling - how does that work when you want to call it from another language ? e.g. for instance you can call C++ code directly through some dialects of Lisp, Perl , ADA, or D (AFA…

If you want to call Rust code from another language, you use its FFI tools to export an un-mangled API. This is typical for C++ as well- trying to interop with mangled C++ names requires a lot of coordination across the toolchains and so even the examples you cite don't work without a lot of pain. If you do wind up exporting the same name twice, you just get a linker error, because Rust doesn't play the same games C+…

> If you want to call Rust code from another language, you use its FFI tools to export an un-mangled API.

this does not answer the question of whether the behaviour is defined if multiple libraries export the same name (which is the original question). See my other comment, what happens if from rust code you dlopen libbar.so ?

Re: Assorted Thoughts on Zig and Rust

#234

Post by JoshTriplett »

tym0 wrote: post #184
steveklabnik wrote: post #180

Earlier quoted context omitted.

If you have foo/mod.rs you can now use foo.rs that's it. Contents of the file are exactly the same. Nothing to do with changing the mod line, or the use line. Those all stay the same. It's about files in the filesystem.

It's my bad I thought I could remove the mod.rs that just redeclares the submodules in my case.

If you'd like to have two modules, `main.rs` and `foo/bar.rs`, and you want the latter to be `foo::bar`, you can do this in `main.rs` to avoid needing a foo.rs that just does `mod bar;`:

    mod foo {
        mod bar;
    }

Re: Assorted Thoughts on Zig and Rust

#235

Post by [deleted] »

jcelerier wrote: post #232
jcelerier wrote: post #230

Earlier quoted context omitted.

> It carefully designs its name mangling such that this doesn't happen in the first place, even in the presence of multiple slightly-different builds of a library. but, after checking apparently this adds a hash of the function to the name mangling - how does that work when you want to call it from another language ? e.g. for instance you can call C++ code directly through some dialects of Lisp, Perl , ADA, or D (AFA…

carefully designed LOL what kind of joke is this $ echo "pub fn my_function() -> i32 { 0 }" > bar.rs ; rustc --crate-type=dylib bar.rs && nm -A libbar.so| grep my_fun _ZN3bar11my_function17hce21faeb92ac13c6E $ echo "pub fn my_function() -> i32 { 1 }" > bar.rs ; rustc --crate-type=dylib bar.rs && nm -A libbar.so| grep my_fun _ZN3bar11my_function17hce21faeb92ac13c6E

[deleted]

Re: Assorted Thoughts on Zig and Rust

#236

Post by JoshTriplett »

nicoburns wrote: post #222
skohan wrote: post #178

Earlier quoted context omitted.

Yeah I just think it’s a trend with rust where when a new user complains about a beginner-unfriendly feature, often they are met with an explanation of some esoteric benefit. I just wonder how much of that is as-hoc reasoning, and it doesn’t seem like it’s a particularly good sign.

I actually the module system is one of the few exceptions where it's actually poorly designed. It could very easily have a 1:1 mapping to the filesystem with no need to declare modules to use them. Lot's of people apparently don't like that idea, but most other module systems do it that way, and IMO it would be a lot more intuitive.

> It could very easily have a 1:1 mapping to the filesystem with no need to declare modules to use them.

I would love to see this. The issue isn't that people hate the idea. The issue is not breaking existing projects and workflows when making such a change. If we could find a way to make this work without breaking existing projects and workflows, I think there's support for doing so.

Re: Assorted Thoughts on Zig and Rust

#237

Post by JoshTriplett »

sacado2 wrote: post #68
lambda_dn wrote: post #11

I think Zig's biggest advantage is that it's just C without the warts, or footguns as is said in the Zig world. The comptime feature is probably the most exciting thing I've seen in a while. I've looked at Rust and feel it's more of a competitor to C++, Java and C#. Whereas Zig is C done right.

Yes. I think Zig is a safer C, while Rust is a safer C++. C programmers will be more excited by Zig than by rust, and the opposite is true for C++ afficionados.

> C programmers will be more excited by Zig than by rust

I'm a C programmer. I haven't touched C++ since before C++11 became a thing, and I prefer C to C++. I'm much more excited by Rust.

Re: Assorted Thoughts on Zig and Rust

#238

Post by moldavi »

coldtea wrote: post #90
flohofwoe wrote: post #64

Earlier quoted context omitted.

Keep in mind that a HTTP server is only useful for a subset of users, it might be an "obvious" requirement for you, but it definitely isn't for me ;) Features like this should go into libraries, but not the standard library. When looking for a Go or Python alternative, Zig doesn't immediately come to mind TBH. Also: Go (or python) has no UI system or 3D API wrapper in the standard library, but those are (probably) us…

> Keep in mind that a HTTP server is only useful for a subset of users, it might be an "obvious" requirement for you, but it definitely isn't for me ;) Yes, but that "subset" is huge. > Also: Go (or python) has no UI system or 3D API wrapper in the standard library, but those are (probably) useful for at least as many people as a HTTP server. Not in the backend/network server world that Go primarily targets...

Whats your criteria/cutoff for what should be in a standard library?

Re: Assorted Thoughts on Zig and Rust

#239

Post by kristoff_it »

_u9xp wrote: post #121

Zig has very little focus on safety and has had several regressions related to security and correctness, most of which Andrew has said he doesn't care about as much. This concerns me greatly. The discord community operates like a cult (sound familiar, Rust community?) and any criticisms or anything not exuberantly positive results in a flame war. I saw all of that happen several times so far with the community and it…

Junon, you are mistakenly assuming that a language that aims to be safe has to prioritize safety all the way from inception to maturity. Right now Zig has much, much, bigger priorities than safety.

The language is not yet production-ready for almost every production use-case, and that should not be a surprise to anybody that has looked into it a bit. We even had somebody make a "Using Zig in Production" talk that started with a few jokes on how he decided to do so despite Andrew publicly saying that it's too early.

Right now docs, tooling, the self-hosted compiler, making design decisions on corners of the language not yet finalized, getting more contributors, getting funding to speed up development (and give back to contributors), and building up the community are all needs with an immensely higher level of priority.

On the last point, the community, since that's my job, I'll spare a couple more words: "the" discord community doesn't exist. The Zig community is decentralized and anyone is free to start their own space, as stated in the Community wiki page of the project https://github.com/ziglang/zig/wiki/Community

So when it comes to Discord servers, at the moment of writing there are two listed in that document: the older, bigger one, and mine. You are probably talking about the bigger one, where I can see your discussions with other members. From what I can see in the logs, the discussions were calm and reasonable. I also don't see any of the insults that you refer to in your other comments. In case I missed them though, you'd need to raise the problem with the moderators of that space, and not chalk it up to 'the community' being a cult. This is very different compared to how Rust runs its communities btw.

I'm sorry, but from what I can gather in your case you simply had strong opinions on specific topics and other people just disagreed with you, partially for design (i.e. non strictly technical) reasons. From what I can see from your other comments in this thread, my only recommendation is to work on being more dispassionate when approaching a new community and when issuing PRs (btw a good way of avoiding doing useless work is to open an issue first or to find Andrew / other core contributors on IRC and get their opinion). At the end of the day Zig is an opinionated project where Andrew gives the final approval on what the language should or should not be. By missing that nuance, you built up expectations that in the end were unmet, resulting in understandable frustration.

That said, from my PoV, this doesn't justify excessive criticism of Zig and its community.

As for debating changes and raising criticism, we do that too, but to do that successfully you need to understand more the nuances in the history and design of Zig.

https://github.com/ziglang/zig/issues/6600 https://www.youtube.com/watch?v=880uR25pP5U

Re: Assorted Thoughts on Zig and Rust

#240

Post by patrec »

dinglejungle wrote: post #224
dnautics wrote: post #128

Earlier quoted context omitted.

Exactly. You can also use non-comptime functions in comptime, if it avoids certain types of stateful behaviour.

An example of this in the Zig math tests, where it tests calling the same function at both comptime and runtime: https://github.com/ziglang/zig/blob/33c4ad7f3a79aad5d7ea481a...

In common-lisp you could do something equivalent, but you'd have to wrap the definitions you want to be able at both compile and and run time in eval-when.
Post reply on HN