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

251–260 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#251

Post by Quekid5 »

mumblemumble wrote: post #220
murkt wrote: post #194

Earlier quoted context omitted.

If you want to communicate intent, put an underscore in the field name, like it's being done in Python. `field` is "you are invited to read/write this directly", `_field` is "please don't read/write this."

Even in a lot of languages that do have "private", it's still pretty consent-based. Java and C#, for example, don't prevent you from mucking with private members, they just make it inconvenient to do so. I used to be suspicious of the Python approach, because it doesn't even pretend it's enforced by anything but the honor system. But I've discovered that, in practice, my Python-using colleagues are no less likely to…

> But I've discovered that, in practice, my Python-using colleagues are no less likely to respect `_field` than my Java-using colleagues are to respect `private field`.

That's a very interesting observation. You really have to go out of your way to access private fields in Java -- I can only recall about 3-5 instances of doing that in my 15+ years programming in Java. You have to look up a field by name, and call setAccessbile(true) on its reflection... and this is definitely going to raise eyebrows in code review. Some of the DI frameworks do it as a matter of course, but that's kind of a different thing...

(Now, package-private is a different matter. In that case you can[0], just put a class in the same package and access from there. I've done that... twice or so?)

What is your recollection in terms of doing the same thing in Python? Obviously, this is just going to be anecdata, but it could be kind of interesting.

[0] Modules change this a bit, but it doesn't seem modules are really a thing outside the standard library yet. (I'm programming in Scala these days, so haven't kept up with Java practices.)

Re: Assorted Thoughts on Zig and Rust

#252

Post by mateus_amin »

twic wrote: post #24
selfmodruntime wrote: post #10

I enjoy Rust and have been writing it for quite some time. However, I feel like server side languages still have a long way to go. Client-side languages in comparison have been only growing better (one could make a lot of negative points about TypeScript and node in general, but the ecosystem is a joy to work with). I feel like this is because people have accepted C and C++ with their respective pain points for close…

> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. I remain to be convinced that this is possible. Rust's ownership model exerts huge design pressure on its standard library. There are some parts that just wouldn't work without ownership (like guards), and many that are far less ergonomic than they cou…

> If you make a language GC by default with opt-in ownership, what does your standard library look like?

I could see the opposite working out very well. Having a GC type you can box other types in.

https://github.com/Manishearth/rust-gc

Re: Assorted Thoughts on Zig and Rust

#253

Post by jcelerier »

jeremysalwen wrote: post #247
jcelerier wrote: post #232

Earlier quoted context omitted.

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

You missed the c++filt at the end: $ echo "pub fn my_function() -> i32 { 1 }" > bar.rs ; rustc --crate-type=dylib bar.rs && nm -A libbar.so| grep my_fun | c++filt libbar.so:0000000000047230 T bar::my_function::h4ed6ea856a52cd6b So adding a single hash to the end of the symbol is a joke?

I don't think that dlsym would accept "bar::my_function::h4ed6ea856a52cd6b" as a symbol, just like it would not accept "foo(std::vector >&)" and wants "_Z3fooRSt6vectorIiSaIiEE" instead, no ?

To be clear, my comment was about the fact that two different functions produce exactly the same symbol name, c++filt or not, which is not what I was told above in " 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."

I have no particular comments on the idea of using hash though I believe that something that changes 95% of chance error in 0.5% of error (I'd assume, as it took me 10 seconds to find a collision) is very bad - you want errors consistently when you fuck up, not once every hash collision as it sounds like a really really big pain to debug when it happens.

Re: Assorted Thoughts on Zig and Rust

#254

Post by jcelerier »

Rusky wrote: post #248
jcelerier wrote: post #233

Earlier quoted context omitted.

> 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 ?

The behavior in that case is defined by the implementation of dlopen. This is entirely outside of Rust's control, but fortunately it's also perfectly well-defined by the platform. Again, does not intersect with the ODR violations I mentioned originally.

> but fortunately it's also perfectly well-defined by the platform.

that's the same for every language and thus not very relevant. if you have single, static binaries / libraries of course everything is simple, and you'll get linker errors in C++ just like you would in Rust. What is not simple is when you start loading twelve dozen libs at load-time or run-time and it does not seem that Rust defines behaviour any more than C++ in that case.

Re: Assorted Thoughts on Zig and Rust

#255

Post by dinglejungle »

galois198 wrote: post #243

Zig is a very well thought out, pragmatic language. I really want to use it more, but I cannot get past the syntax. For example, method chaining: std.fs.cwd().openFile("does_not_exist/foo.txt", .{}) The aesthetic of a language is really important to me, and method chaining that allows for lines like this somehow doesn't feel right.

Are you saying that the given example should be disallowed?

Re: Assorted Thoughts on Zig and Rust

#256

Post by mumblemumble »

Quekid5 wrote: post #251
mumblemumble wrote: post #220

Earlier quoted context omitted.

Even in a lot of languages that do have "private", it's still pretty consent-based. Java and C#, for example, don't prevent you from mucking with private members, they just make it inconvenient to do so. I used to be suspicious of the Python approach, because it doesn't even pretend it's enforced by anything but the honor system. But I've discovered that, in practice, my Python-using colleagues are no less likely to…

> But I've discovered that, in practice, my Python-using colleagues are no less likely to respect `_field` than my Java-using colleagues are to respect `private field`. That's a very interesting observation. You really have to go out of your way to access private fields in Java -- I can only recall about 3-5 instances of doing that in my 15+ years programming in Java. You have to look up a field by name, and call set…

I've mostly seen it done in situations that are roughly analogous to IoC containers. So, custom serde libraries that use reflection, testing utility code, object mapping tools, magic validators, stuff like that. Which, any sufficiently venerable enterprise Java application seems to have at least one or two of those knocking around the codebase.

FWIW, Java is also where I see stringly typed designs, too. I'm increasingly coming to fear that languages with more safety-oriented features aren't associated with safer practices because those features encourage safer design, so much as because they tend not to attract programmers with a swashbuckling attitude in the first place.

Re: Assorted Thoughts on Zig and Rust

#257

Post by roca »

kristoff_it wrote: post #239
_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 st…

The problem is that safety means, by definition, ruling out unsafe code at compile time or run time. If you don't prioritise safety early then you run a high risk of discovering when you try to retrofit safety later that you need to rule out a lot of existing code. Even if you haven't promised stability, breaking existing code hurts the ecosystem.

Therefore when setting priorities for language evolution it seems better to identify work that is less likely to result in breaking code, and prioritise safety over that.

Re: Assorted Thoughts on Zig and Rust

#258

Post by roca »

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.

The safety guarantees of Rust are much stronger than Zig's. For example Rust statically prevents use-after-free and data races, and Zig doesn't (and I don't think anyone expects it ever to). To me this matters more than which one is more like C or C++ (partly because I don't think Rust is very much like either).

Re: Assorted Thoughts on Zig and Rust

#259

Post by Rusky »

jcelerier wrote: post #254
Rusky wrote: post #248

Earlier quoted context omitted.

The behavior in that case is defined by the implementation of dlopen. This is entirely outside of Rust's control, but fortunately it's also perfectly well-defined by the platform. Again, does not intersect with the ODR violations I mentioned originally.

> but fortunately it's also perfectly well-defined by the platform. that's the same for every language and thus not very relevant. if you have single, static binaries / libraries of course everything is simple, and you'll get linker errors in C++ just like you would in Rust. What is not simple is when you start loading twelve dozen libs at load-time or run-time and it does not seem that Rust defines behaviour any mor…

Right, I've been telling you it's not relevant for the past three comments now.

You seem to be under the impression that dlopen somehow interacts with language undefined behavior; it does not in either Rust or C++.

Re: Assorted Thoughts on Zig and Rust

#260

Post by Quekid5 »

mumblemumble wrote: post #256
Quekid5 wrote: post #251

Earlier quoted context omitted.

> But I've discovered that, in practice, my Python-using colleagues are no less likely to respect `_field` than my Java-using colleagues are to respect `private field`. That's a very interesting observation. You really have to go out of your way to access private fields in Java -- I can only recall about 3-5 instances of doing that in my 15+ years programming in Java. You have to look up a field by name, and call set…

I've mostly seen it done in situations that are roughly analogous to IoC containers. So, custom serde libraries that use reflection, testing utility code, object mapping tools, magic validators, stuff like that. Which, any sufficiently venerable enterprise Java application seems to have at least one or two of those knocking around the codebase. FWIW, Java is also where I see stringly typed designs, too. I'm increasin…

Right, for DI/IoC it seems pretty standard. (I think it's probably a historical accident, honestly. Reflection was really the tool to get constructor parameters and then someone figured, hey, why not just inject private values directy? It surely convenient at the time, but... lessons learned, I guess. I have no problem with compile-time DI via static reflection of e.g. constructors. It's a little more boilerplate, but worth it, IMO)

Definitely agree about "stringly" typed programming becoming an increasing issue in Java over the years, but that had more to do with over-use of instanceOf, etc., not so much actual strings (as in className).

> I'm increasingly coming to fear that languages with more safety-oriented features aren't associated with safer practices because those features encourage safer design, so much as because they tend not to attract programmers with a swashbuckling attitude in the first place.

For the life of me I cannot parse this sentence. Could you please rephrase or expound? Is there a missing negative somewhere, or...?

Post reply on HN