Assorted Thoughts on Zig and Rust • Hacker News Board

Re: Assorted Thoughts on Zig and Rust

#111

Post by rob74 » Tue, Oct 20, 2020, 2:23 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…

On the other hand, more often than not the developer who is (more or less hurriedly) adding code is trying to do something that the original designer didn't think of beforehand, and because of that they now have to jump through additional hoops to make it work...

Re: Assorted Thoughts on Zig and Rust

#112

Post by qayxc » Tue, Oct 20, 2020, 2:24 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.…

> The real future though is theorem proving systems, and generating code from them.

I've heard the same thing about model-driven development 25 years ago. Outside of some very small niches, it's pretty much dead now.

> But theorem proving systems that embrace the full spectrum of abstract and correct thought.

And here's where reality and the ideal world collide: the vast majority of applications consists of incomplete models (in that data and/or understanding of the problem are incomplete), quickly shifting goals, and pressure to release.

Theorem proving systems offer nothing that helps with this class of software - abstract and correct thought sounds marvellous in an academic environment or if you have unlimited budget to hire top talent and perform thorough analysis.

In practice, however, your typical line-of-business application is faster, cheaper, and well-enough programmed using traditional languages and a healthy dose of best-practises.

Optimisation and platform support are another area where a TPS won't be very useful. Every hardware has its quirks and workarounds are required to get the best performance or avoid pitfalls. These aren't easily expressed (and identified) using abstract thought and models.

Last but not least, no sane company is going to just throw away decades worth of investment in applications, libraries, and (software-)infrastructure just for a nebulous promise of what basically boils down to smarter and better staff with the right tools.

Theorem proving systems have their place and that place might get bigger in the future, but they're most certainly not the panacea of all software development.

Re: Assorted Thoughts on Zig and Rust

#113

Post by IridescentRose » Tue, Oct 20, 2020, 2:30 PM UTC

fwsgonzo wrote: post #84

nimmer wrote: post #57

Pity that Nim was not part of the article.

It's weird because out of all the languages I have made a special environment for, Zig is the only one I couldn't figure out how to. For example, how to write global asm? How to call the Zig main function? I guess I need a trampoline? I have an emulated env with no filesystems and such things, where you just communicate using system calls - so nothing special, however since you can't just use the standard libraries I…

Global Asm:

  comptime{
    asm("nop"); //Your asm here
  }

Calling Main From an arbitrary point:

  const root = @import("root");

  //....

  root.main();

Re: Assorted Thoughts on Zig and Rust

#114

Post by geodel » Tue, Oct 20, 2020, 2:30 PM UTC

robinei wrote: post #78

weinzierl wrote: post #4

Earlier quoted context omitted.

While Zig is an awesome project I feel a little bit the same. My two cents are that it is because Zig, as innovative as it is, has nothing that other languages couldn't copy or assimilate. With Rust it is a different story, because the ownership model cannot be plugged into other languages without changing them fundamentally. My prediction is similar to yours that Zig will be an important research project but not go…

I have the feeling that what will push Zig ahead is the uncanny sense of technical aesthetics shown by the creator. Unsexy details like language simplicity, what-you-read-is-what-runs, orders of magnitude faster compile times, effortless cross compilation and C interoperability. I have never seen anyone focusing so ruthlessly, so early, on nitty-gritty details of how to go about engineering a compiler and language th…

This is excellent point. Zig authors like Go authors prioritize software engineering and hence upfront work on tooling, fast compilers, cross compilation etc. Whereas a lot of upcoming languages in last decade are prioritizing PL design part, so tooling will be delegated to external projects.

I have seen many say just combine PL design innovation and tooling part and it will be perfect but I think this will not happen because it becomes very difficult and sensibilities of these approaches do not match.

Re: Assorted Thoughts on Zig and Rust

#115

Post by patrec » Tue, Oct 20, 2020, 2:34 PM UTC

creata wrote: post #105

patrec wrote: post #100

Earlier quoted context omitted.

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.

I could write a concrete example that will work in zig and fail in common lisp, but maybe this link is enough?

https://ziglang.org/#Order-independent-top-level-declaration...

Re: Assorted Thoughts on Zig and Rust

#116

Post by scoutt » Tue, Oct 20, 2020, 2:36 PM UTC

martinhath wrote: post #65

pizza234 wrote: post #38

I think this an argument like the following is not really meaningful: > Most of this difference is not related to lifetimes. Rust has patterns, traits, dyn, modules, declarative macros, procedural macros, derive, associated types, annotations, cfg, cargo features, turbofish, autoderefencing, deref coercion etc Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the ne…

> Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any. Macros in Rust aren't only confusing for beginners, because it has a completely different syntax (well, at least macro_rules! does; idk about proc macros) than the one you use fo…

> the Rust community tries really hard to combat

How? My impression is that they are not trying to do the language easier at every release. Contrarily, I see more new features added all the time (which is a good thing if Rust is your thing).

What I see is top-quality documentation. No doubt about it. Perhaps they focus on quality learning material, but the truth is the more I read, the more I scratch my head thinking "what is this construct and when and why do I need to use this?". Then overchoice[1] anxiety kicks in and I go back to zero, that is, my good old C.

[1] https://en.wikipedia.org/wiki/Overchoice

Re: Assorted Thoughts on Zig and Rust

#117

Post by q3k » Tue, Oct 20, 2020, 2:37 PM UTC

rob74 wrote: post #111

mcherm wrote: post #92

Earlier quoted context omitted.

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

On the other hand, more often than not the developer who is (more or less hurriedly) adding code is trying to do something that the original designer didn't think of beforehand, and because of that they now have to jump through additional hoops to make it work...

This is a good observation. Some of the best codebases I’ve worked with are the ones whose authors insisted on keeping things easy to modify or remove (not by introducing unnecessary abstraction, but by simplifying things as much as possible). Some of the worst codebases are those where the author assumed that their elegant solution is ultimate and will never be read in circumstances other than to be admired.

Re: Assorted Thoughts on Zig and Rust

#118

Post by xiaodai » Tue, Oct 20, 2020, 2:37 PM UTC

this reads like a really well researched post

Re: Assorted Thoughts on Zig and Rust

#119

Post by lifthrasiir » Tue, Oct 20, 2020, 2:37 PM UTC

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…

>> Zig manages to provide many of the same features with a single mechanism - compile-time execution of regular zig code.

> This is a huge one for me, and I really don't understand why Rust didn't jump on this earlier.

I believe this outcome was mostly defined by the history. Here is my reasoning:

Rust, at least since 0.5, was undoubtly designed as a replacement for C++ (of course that doesn't necessarily mean that it only appeals to C++ programmers), and C++ was notable for its unexpected sophiscation and problems with its primary compile-time mechanism, templates in the other words.

Rust replaced templates with two other features: traits and reimagined syntactic macros. The former formalizes C++'s long-waited concepts feature and avoids issues with C++'s "ad hoc" polymorphism, while the latter deals with code generation, the remaining use of templates.

Traits (and lifetimes) required a complex type system, which takes time to compute and ideally the result for some file should be intact when other files have been changed. This constraint makes most additional compile-time mechanisms undesirable for addition because they can create unexpected dependencies between files, so recompiling one can trigger others. Note that the compile-time code is still a code, with states and everything attached, so this is far from trivial. (What if your compile-time code needs an external input?)

Zig and Nim show what the different starting point might result in: they didn't have to solve problems with C++ templates (among others), and could retain ad hoc polymorphism. This limits an ability to incrementally compile, and what's common with those languages? Much simpler type system, which compiles fast and makes the incremental compilation less concern for them. Rust needed a complex type system for its goals, which unfortunately limited its options for compile-time mechanisms.

Re: Assorted Thoughts on Zig and Rust

#120

Post by lzutao » Tue, Oct 20, 2020, 2:39 PM UTC

fwsgonzo wrote: post #84

nimmer wrote: post #57

Pity that Nim was not part of the article.

It's weird because out of all the languages I have made a special environment for, Zig is the only one I couldn't figure out how to. For example, how to write global asm? How to call the Zig main function? I guess I need a trampoline? I have an emulated env with no filesystems and such things, where you just communicate using system calls - so nothing special, however since you can't just use the standard libraries I…

> there is no feature in Rust to force a function to not be removed

Can we use `pub` to make it public and not to be removed ?