Live data from Hacker News

Assorted Thoughts on Zig and Rust

scattered-thoughts.net

241–250 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#241
post #184

Earlier quoted context omitted.

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; }

I was just following the example from the docs, my use case is more like this:

  .
  ├── lib.rs
  └── foo/
    └── mod.rs
    └── one.rs
    └── two.rs
    └── three.rs
    └── four.rs
  └── bar/
    └── mod.rs
    └── one.rs
    └── two.rs
    └── three.rs
    └── four.rs
Which feels to me like a very common folder structure in other languages.

Re: Assorted Thoughts on Zig and Rust

#242

Very interesting set of observations. As a C and C++ programmer, I am feeling more and more excited about Zig. One thing that feels missing from Zig though is encapsulation. I don't believe that you can declare struct fields private, such that they can only be accessed by methods. This seems really important to me, not only as a technical means of enforcing invariants, or hiding internal-only implementation details t…

I'm 90% in favor of this; the 10% comes from the few times where I've wished that a particular field was exported, and I know it would be safe to access, but now I need to open an issue or submit a patch, wait for it to be merged upstream, update the dependency version... Give that Zig is a low-level language where "unsafe escape hatches" are the norm, it wouldn't surprise me if this ended up being an optional compil…

I'm ok with an escape hatch. I'm even ok with a strong convention. My primary concern is that there is a clear contractual line between "reading/writing this is supported" and "you're on your own."

Re: Assorted Thoughts on Zig and Rust

#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.

Re: Assorted Thoughts on Zig and Rust

#244
post #168

> Zig is dramatically simpler than rust... Most of this difference is not related to lifetimes. I've been thinking about this recently: the borrow checker gets a lot of attention, but I think the majority of the learning curve of rust is actually due to "unforced errors" in the language UX which have nothing to do with the language's core USP's. For instance, the module system just seems needlessly complex. Like you…

I don't think this is fair. There is definitely some unforced error, but a lot of the complexity is shared with other languages in it's heritage eg the trait system is no more complicated than haskell's typeclasses, and haskell also has macro systems on top of that.

Also the simplicity in zig comes from a major innovation in controlled partial evaluation, which we've yet to really explore the consequences of. Rust had already made a major innovation in the form of the lifetime system. It needed to figure out all the implications of that so it made sense to draw from existing designs where possible for the rest of the language rather than piling on more new and untested ideas.

Re: Assorted Thoughts on Zig and Rust

#245

Very interesting set of observations. As a C and C++ programmer, I am feeling more and more excited about Zig. One thing that feels missing from Zig though is encapsulation. I don't believe that you can declare struct fields private, such that they can only be accessed by methods. This seems really important to me, not only as a technical means of enforcing invariants, or hiding internal-only implementation details t…

I believe zig does not intend to implement this eg https://github.com/ziglang/zig/issues/2479#issuecomment-5709...

Naming conventions seem like the way to go.

Re: Assorted Thoughts on Zig and Rust

#246

Earlier quoted context omitted.

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.

The new module system is already incompatible with pre-2018 edition projects, so I don't know why this argument explains why the current module system doesn't bite the bullet and use the file system hierarchy.

Re: Assorted Thoughts on Zig and Rust

#247

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

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?

Re: Assorted Thoughts on Zig and Rust

#248
post #231

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

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.

Re: Assorted Thoughts on Zig and Rust

#249
post #246

Earlier quoted context omitted.

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

The new module system is already incompatible with pre-2018 edition projects, so I don't know why this argument explains why the current module system doesn't bite the bullet and use the file system hierarchy.

> The new module system is already incompatible with pre-2018 edition projects

Code written for the 2015 edition should generally just work with the 2018 edition module system. That's part of what we worked to ensure, and that's why we didn't mix in changes that might have reduced that compatibility.

Re: Assorted Thoughts on Zig and Rust

#250
post #164

Earlier quoted context omitted.

I have some frontend developers in my team who think java is slow, but wait minutes waiting for NPM to finish its job. Our backend code builds 3x faster than our frontend code these days.

But is that because of npm, or is it because of their massive array of dependencies, plus webpack, bable, pollyfills and whatever 5 transpilers they have integraated into their project?

In my experience, it is both.
Post reply on HN