Assorted Thoughts on Zig and Rust • Hacker News Board

Re: Assorted Thoughts on Zig and Rust

#101

Post by k__ » Tue, Oct 20, 2020, 1:53 PM UTC

kzrdude wrote: post #52

k__ wrote: post #44

Earlier quoted context omitted.

You're right, but I find Rusts concepts/keywords also a bit confusing. I know what a class and what an interface is, but Rust doesn't have these. It has a struct, which is kinda like a class without methods? It has a trait, which is kinda like an interface but with implementations for methods? It has ... implementations... which kinda make a struct to a class, but not really. I don't mean to hate here, but these are…

Once understood, even taken together, none of those have as many rules baked into one concept as "class" does; each is simple.

Less rules doesn't mean simpler.

Also, I don't mean Rust is harder than C++ or Java. It's just quite different.

If you are used to visualizing software as graphs of functions or classes in your mind for years, switching to the Rust model is quite a change of thinking.

Re: Assorted Thoughts on Zig and Rust

#102

Post by auggierose » Tue, Oct 20, 2020, 1:55 PM UTC

None of these languages represent the medium term future, but are certainly interesting milestones along the way that will inform it.

The real future though is theorem proving systems, and generating code from them. I don't mean so much Agda, Idris, etc., which try to approach theorem proving from a programmer's point of view. But theorem proving systems that embrace the full spectrum of abstract and correct thought.

Zig and Rust try to get there without paying the heavy price that theorem proving incurs (Rust pays that price more than Zig already, though). But to truly progress we need to pay that price and make it lower and lower with time.

Re: Assorted Thoughts on Zig and Rust

#103

Post by martinhath » Tue, Oct 20, 2020, 1:55 PM UTC

steveklabnik wrote: post #77

martinhath wrote: post #61

This is a really great writeup! I was using Rust as my main programming language from some months before 1.0 up until maybe early 2019. I have only written somewhere in between 100 and 1k lines of Zig, but generally feel that I agree with most of what's being brought up here. Here's a mind dump: > Zig manages to provide many of the same features with a single mechanism - compile-time execution of regular zig code. Th…

(By the way, Hacker News doesn't support markdown; indent your code by two spaces, rather than using fences. https://news.ycombinator.com/formatdoc ) Just a few small things: > This is a huge one for me, and I really don't understand why Rust didn't jump on this earlier. Doing this well is not easy. Exposing a full language at compile time isn't a difficult feature, but doing compile-time execution in a sound, safe w…

> doing compile-time execution in a sound, safe way is not simple. For example, cross compilation becomes more of a thing. It is easy to accidentally break the type system.

Why? I don't think I've ever seen a concrete example of why this isn't simple (but I'm not really a compiler person, so there might be!). I can imagine plenty of ways of doing Bad Things, like adding compiler flags based on what day it is, but I can't immediately see why this would _break_ anything. What do you mean by breaking the type system? Accidentally getting non-typechecked code in the compiler, or running into problems with the compiler thinking two equal types are distinct?

> There's just not a lot to say. The exact details are being worked on. This takes time.

I understand and appreciate this! Maybe I should've phrased myself better: I don't understand how people are using `unsafe` today successfully when something as fundamental to the Rust language model such as aliasing isn't really defined properly yet. It sound like people writing books without the rules on verb conjugation being really set. It sounds to me like plenty of the unsafe code out there might end up breaking at some point, and that, by extension, all other safe code out there is basically built on extremely shaky grounds.

I might be overreacting here though, since I don't write a whole lot of Rust anymore and am pretty distanced from the community. Considering their track record, I'm sure it'll turn out just fine.

---

> (By the way, Hacker News doesn't support markdown;

Ah! It's always tricky to remember which places support what syntax with these things. Thanks!

Re: Assorted Thoughts on Zig and Rust

#104

Post by hobofan » Tue, Oct 20, 2020, 1:57 PM UTC

mtzet wrote: post #83

steveklabnik wrote: post #77

Earlier quoted context omitted.

(By the way, Hacker News doesn't support markdown; indent your code by two spaces, rather than using fences. https://news.ycombinator.com/formatdoc ) Just a few small things: > This is a huge one for me, and I really don't understand why Rust didn't jump on this earlier. Doing this well is not easy. Exposing a full language at compile time isn't a difficult feature, but doing compile-time execution in a sound, safe w…

> Doing this well is not easy Does this also apply to the in-language build system? Given both Rust and Zig's ergonomics, it just seems so brilliantly simple (at least in hindsight) to let the build system be a library. Is it just coincidence that I've only heard of this approach for zig and Jonathan Blow's language, or is there a technical reason this is more difficult than it seems?

In case you didn't know, cargo is available as a library as well[0].

I don't know why the current Zig approach[1] would be preferable, as you dump some source code that you are now responsible to maintain in your project. Any bigger project project will require writing boilerplate code just to get things built.

It's also a bit of comparing apples to oranges, as Zig's build system doesn't come with a package manager (which I would say makes up a good chunk of Cargo's complexity).

[0]: https://crates.io/crates/cargo

[1]: https://ziglang.org/#Zig-Build-System

Re: Assorted Thoughts on Zig and Rust

#105

Post by creata » Tue, Oct 20, 2020, 2:10 PM UTC

patrec wrote: post #100

moomin wrote: post #98

Earlier quoted context omitted.

But comptime is kind of LISP's unique feature, it's just called macros. EDIT: In fairness, Zig's presentation is pretty likeable. You can do a comptime expression pretty trivially in LISP, a comptime parameter or block would require actual effort.

No. There is a real difference between staged computation of the type that zig has and macros in common lisp, scheme/rust have (so much for lisp's uniqueness BTW). In common lisp you can do completely arbitrary computation at compile- (or read-)time in zig you cannot and crucially you are also not responsible for manually ordering the "stages". E.g. in common lisp you have use eval-when to make sure that stuff is ava…

Can you please provide an example of Zig "working out the dependency"? I'm struggling to make sense of your comment.

Re: Assorted Thoughts on Zig and Rust

#106

Post by lenkite » Tue, Oct 20, 2020, 2:12 PM UTC

auggierose wrote: post #102

None of these languages represent the medium term future, but are certainly interesting milestones along the way that will inform it. The real future though is theorem proving systems, and generating code from them. I don't mean so much Agda, Idris, etc., which try to approach theorem proving from a programmer's point of view. But theorem proving systems that embrace the full spectrum of abstract and correct thought.…

Would love a real programming language where one can write subroutines and structures that are directly checked for logical correctness and performance. Having to rewrite something in an alternative language to prove correctness is a major pain.

Re: Assorted Thoughts on Zig and Rust

#107

Post by steveklabnik » Tue, Oct 20, 2020, 2:18 PM UTC

martinhath wrote: post #103

steveklabnik wrote: post #77

Earlier quoted context omitted.

(By the way, Hacker News doesn't support markdown; indent your code by two spaces, rather than using fences. https://news.ycombinator.com/formatdoc ) Just a few small things: > This is a huge one for me, and I really don't understand why Rust didn't jump on this earlier. Doing this well is not easy. Exposing a full language at compile time isn't a difficult feature, but doing compile-time execution in a sound, safe w…

> doing compile-time execution in a sound, safe way is not simple. For example, cross compilation becomes more of a thing. It is easy to accidentally break the type system. Why? I don't think I've ever seen a concrete example of why this isn't simple (but I'm not really a compiler person, so there might be!). I can imagine plenty of ways of doing Bad Things, like adding compiler flags based on what day it is, but I c…

> Accidentally getting non-typechecked code in the compiler, or running into problems with the compiler thinking two equal types are distinct?

Yes, this sort of thing. Basically, you have to have this be deterministic, or you end up with very strange possibilities, possible miscompilations, and in the best case, confusing errors. One option is to simply accept that these things can happen. Another is to restrict what you can do at compile time to ensure that they can't.

An extremely simple example is cross compiling. In Rust, usize is dependent on the architecture you're compiling for. A very simple "just compile and run the program, get the answer, and use it" implementation of compile-time execution will produce a usize of the size of the host, not the target. That's a miscompilation. This example, while being simple, is also simple to fix. But it's an example of how it's not as trivial as "use the compiler to compile the program, then run it." Which maybe isn't how you think of this feature, but how I was, back before I knew anything about this topic :)

> I might be overreacting here though

Nah, I think that you're not wrong. It's just that, when you start applying this super rigorously, you end up in weird places. How can you trust any behavior in a language without a specification? How you can you trust a specification if that specification hasn't been formally proven? How you can trust an implementation of a formally proven specification? How you can you trust that the silicon you're running on does the right thing, even with your bug free, formally proven code?

Everyone chooses somewhere along this axis to be comfortable with. And everyone does something, including "I can ignore these problems because in practice they don't happen to me," to deal with the bits outside of what they consciously choose to focus on.

Re: Assorted Thoughts on Zig and Rust

#108

Post by giraj » Tue, Oct 20, 2020, 2:19 PM UTC

auggierose wrote: post #102

None of these languages represent the medium term future, but are certainly interesting milestones along the way that will inform it. The real future though is theorem proving systems, and generating code from them. I don't mean so much Agda, Idris, etc., which try to approach theorem proving from a programmer's point of view. But theorem proving systems that embrace the full spectrum of abstract and correct thought.…

Could you elaborate or illustrate what you mean by "theorem proving systems that embrace the full spectrum of abstract and correct thought"?

As a mathematician (and programmer on the side) who regularly works in Coq, my impression is that Rust does represent "the future of programming" (or rather, my ideal of it). Type systems are the only mechanism (that I know of) for formally ensuring properties of programs, and proof assistants and languages like Rust lie on two extremes of the spectrum. The former puts the type system in focus; indeed all my work in Coq is about convincing the compiler that certain functions (terms) type-check. The latter puts types in the background, trying to prove as much as possible with minimal friction.

What's the alternative?

Re: Assorted Thoughts on Zig and Rust

#109

Post by lenkite » Tue, Oct 20, 2020, 2:19 PM UTC

skohan wrote: post #20

peteretep wrote: post #13

Earlier quoted context omitted.

> node ... the ecosystem is a joy to work with I'm not entirely sure I've heard anyone express this before. What do you like about it?

I actually think NPM is an amazing tool. When comparing to many other dependency management solutions, NPM: 1. has a nicer user experience 2. gives a lot of confidence that a project will be reproducible across environments, with only a package.json file Cargo is pretty close, but NPM is the gold standard for dependency management as far as I'm concerned.

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.

Re: Assorted Thoughts on Zig and Rust

#110

Post by smiths1999 » Tue, Oct 20, 2020, 2:21 PM UTC

mcherm wrote: post #92

q3k wrote: post #72

Earlier quoted context omitted.

As coined by Google engineers: software engineering is programming integrated over time. Languages that are paragons of cutting edge PL research unfortunately tend to forget that. Go’s simplicity tends to be brought up as a negative trait (dumb language, dumb users, etc) mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codeba…

> Go’s simplicity tends to be brought [...] mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codebase to do the same thing. Last thing on your mind then is the type safety and elegance of a language. Actually, type safety can be quite useful in such a context: it allows the person who designed the types in use to enforce cert…

I don't disagree, but this goes both ways (and I typically only see one side of this argument put forward). They also allow the person who designed the types to make the types so complex that the average user cannot understand what is going on. You may argue "well that person has no business looking at the code" but sometimes you have to look into other people's code when you are debugging an issue.

No doubt type systems can allow you to write safer, more robust code. But they can also allow you to introduce new risks to your codebase, one of which is difficult to read/understand code.