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

271–280 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#271

Post by kristoff_it »

roca wrote: post #257
kristoff_it wrote: post #239

Earlier quoted context omitted.

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 bett…

Your are correct, yet general statements. The situation in the Zig ecosystem right now is not one based on "retrofitting" security into the language, but, if today we don't have a function that sanitizes utf8 in the standard library, that doesn't mean that the language is going to become a swiss cheese in terms of security.

Please read Andrew's answer and check the linked project management dashboard on GH.

Re: Assorted Thoughts on Zig and Rust

#272

Post by jeremysalwen »

jcelerier wrote: post #253
jeremysalwen wrote: post #247

Earlier quoted context omitted.

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…

I see, I misunderstood your comment as about the mangling convention, not about the collision.

Re: Assorted Thoughts on Zig and Rust

#273

Post by jamii »

kzrdude wrote: post #58
IshKebab wrote: post #18

> Both languages will insert implicit casts between primitive types whenever it is safe to do so, and require explicit casts otherwise. I think Rust always requires explicit casts. It's a bit annoying tbh - especially for array indexing - indexing with a u8, u16 or u32 should always be fine but you still have to do `as usize`.

It is annoying since in relationship to bounds checking, we could write a non-surprising automatic conversion - given array length type and index type, we'd need to cast to the bigger of the two and make the bound check. But it doesn't mesh well with the fact that all but primitive indexing are implemented in the library, and is not built in.

I guess Index could be implemented on some type for both u32 and usize and then upcasting a u32 would produce ambiguity.

Re: Assorted Thoughts on Zig and Rust

#274

Post by zem »

jamii wrote: post #270
zem wrote: post #217

my ears pricked up at the mention of gtk apps for the pinephone; i was planning on exploring rust and D to do precisely that. will definitely add zig to the mix now.

Here's how I set up the cross-compile in zig - https://scattered-thoughts.net/writing/pinephone-first-steps... That only covers gl/sdl but I think gtk worked with that method too.

thanks! when i had my n900 i used vala for the same use case (small, quick apps that were just for me to use) but the language is getting a bit long in the tooth :)

Re: Assorted Thoughts on Zig and Rust

#275

Post by estebank »

jamii wrote: post #273
kzrdude wrote: post #58

Earlier quoted context omitted.

It is annoying since in relationship to bounds checking, we could write a non-surprising automatic conversion - given array length type and index type, we'd need to cast to the bigger of the two and make the bound check. But it doesn't mesh well with the fact that all but primitive indexing are implemented in the library, and is not built in.

I guess Index could be implemented on some type for both u32 and usize and then upcasting a u32 would produce ambiguity.

This is indeed the main reason array[42u32] isn't supported today: implementing Index on both usize and u32 would make array[42] ambiguous for the type system, it needs to unify the {integer} literal and some implementor of Index, but there are now two possibilities. This would be a breaking change.

Re: Assorted Thoughts on Zig and Rust

#276

Post by est31 »

skohan wrote: post #172
steveklabnik wrote: post #169

Earlier quoted context omitted.

mod.rs isn't needed anymore; back in 2018 we fixed that: https://doc.rust-lang.org/edition-guide/rust-2018/module-sys... > why there can't be sensible defaults to define modules based on the file system structure alone. There could be, and in fact, I personally advocated for them. But there was significant community pushback; it turns out many people like to "comment out" entire modules when doing big refactorings. T…

> mod.rs isn't needed anymore; So I'm not sure I'm a fan of this either. So now for a module with sub-modules, part of it is defined in the top-level directory, and part of it is defined in a sub-directory. Now if I want to move a module from one directory to another, I have to move two items in the file system. > it turns out many people like to "comment out" entire modules when doing big refactorings. It seems to m…

> > mod.rs isn't needed anymore;

I think the main reason why the foo.rs foo/bar.rs stuff was done was so that the tabs in an editor have informative headings. Instead of ten times mod.rs you have foo.rs, baz.rs, test.rs and so on. Personally I don't like it either (for the same reason as you) but the old way is still possible, even on the 2018 edition, so that's what I use.

Re: Assorted Thoughts on Zig and Rust

#277

Post by est31 »

pron wrote: post #197
Rusky wrote: post #177

Earlier quoted context omitted.

I really don't see how Rust has most of C++'s problems. Slow compiler, sure, though things are changing. Most complex languages in history? Only if you squint at it from 10000 feet and ignore what the complexity is doing. C++ has approximately eighteen different partially-overlapping categories of variable initialization, many of which are legacy-but-still-used! [0] And some of those categories have changed their bou…

You're comparing 35-year-old C++ with 10-year-old Rust (and that doesn't even capture the story, because after two years C++ had something like 5x the market penetration Rust has after ten). But even now Rust, I think, together with C++, Ada, and Scala, easily ranks among the top five or so most complex programming languages in software history. It's definitely a matter of personal taste, but to me , Rust seems a mon…

> because after two years C++ had something like 5x the market penetration Rust has after ten

C++ is highly backwards compatible to C to the degree that it's almost (but not quite) a superset. Of course it's quite easy to start creating cpp files. Also C++'s benefits were quickly realizable while for Rust's safety benefits to play out, you need to have replaced significant portions of highly risky components (e.g. those that parse user data, have a history of bugs, etc). Adding Rust to an existing C++ codebase is much harder than adding C++ to an existing C codebase.

Also do you have a link for your claim? I'm interested in reading on the early rise of C++.

Re: Assorted Thoughts on Zig and Rust

#278

Post by Jayschwa »

ironmagma wrote: post #203
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.

It's almost just C without the warts; I wish someone would make a language that was both as good as Zig or Rust, and could be compiled to C code. The dependency on LLVM rules out a lot of embedded use cases, because some chipsets require forks of LLVM, or worse, proprietary C compilers or forks of GCC or something else, to run. Would be nice to have a language that just works everywhere.

> I wish someone would make a language that was both as good as Zig or Rust, and could be compiled to C code.

Zig will eventually have this feature. It is a work-in-progress: https://github.com/ziglang/zig/blob/master/src/codegen/c.zig

Re: Assorted Thoughts on Zig and Rust

#279

Post by bumblebritches5 »

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…

Then learn C#.

garbage collection is a hard no for a system language.

Re: Assorted Thoughts on Zig and Rust

#280

Post by kbenson »

steveklabnik wrote: post #181
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 thought this way too until I saw a bunch of people praising how easy the module system was because they felt it was very similar to Python's. I don't know Python well so I can't speak to it. My working theory: each language does modules in a different way. People think "Oh, a module system, I know this" and then run into issues when it works differently than their language. Just a theory though, I have not been abl…

Honestly, that idea makes a lot of sense to me, and personally, I find the module system pretty normal seeming for a modern language. I'm used to Perl and CPAN, and it's pretty similar to that, except for the option to use dir/mod.rs, which honestly seems like it's kinda nice for keeping a module contained nicely for those that want to do it that way.

Now I'm more interested in what the complaints about it are, and specifically what they're in comparison to. Either they're not used to using so many modules in a method such as this, or they're honestly expecting some better system for their use case that I'm unaware of, or a little of both, so my curiosity is piqued.

Post reply on HN