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

191–200 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#191

Post by optymizer »

wk_end wrote: post #132
optymizer wrote: post #80

Earlier quoted context omitted.

I've been enjoying D as "C done right". I find it a pleasure to use.

D is much more "C++ done right" (and then some). C and Zig are very barebones, close-to-the-metal language. D has garbage collection, classes, templates, exceptions, built-in dynamic arrays and hash tables, and on and on and on. The "Features Overview" page makes me go cross-eyed [1]. Yes, you can turn many of these things off or ignore them and just use D as a better C, but the same could be said of C++ (for some de…

Yes, and people do use C++ as a better C to get OO and a stronger type system, at the cost of compilation times (and the usual C++ pitfalls).

I use D as better C. I use it as better C++ at times. Once ownership/borrowing [1] is stable, I'll use it as a better Rust too.

For close-to-the-metal code, I use D's inline assembler [2]. "To go any lower level than that, you'd need a miniature soldering iron and a very, very steady hand." (Andrei Alexandrescu)

[1] https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

[2] https://dlang.org/spec/iasm.html

Re: Assorted Thoughts on Zig and Rust

#192

Post by kzrdude »

q3k wrote: post #79
kzrdude wrote: post #53

Earlier quoted context omitted.

Why a http server in the standard library? It's quite likely to end up where Python 3's http.server module is: "Don't use this in production". So when can I then use it? It's mostly a party trick of a module, then.

Yet, Go’s net/http client/servers are fully production ready. This can be done right. Being able to just use them without having to follow the newest trends in a language’s ecosystem is a huge cognitive burden off my mind.

That is great.

Maybe I should ask, what is it that makes Python standard lib modules likely to end up like this? The list is pretty long.

Re: Assorted Thoughts on Zig and Rust

#193

Post by optymizer »

fanf2 wrote: post #183
optymizer wrote: post #174

Earlier quoted context omitted.

I invite you to use D's -betterC compiler option and evaluate it in the context of C/C++/Rust.

As I understand it, that means you can't benefit from most of the D standard library and ecosystem

You can use packages that have been converted to not use the GC and all of the libraries you would be using in C or C++.

You still get the following language features, which is more than what C, C++ or Rust have to offer (though Rust is hot on D's trail).

   Unrestricted use of compile-time features
   Full metaprogramming facilities
   Nested functions, nested structs, delegates and lambdas
   Member functions, constructors, destructors, operating overloading, etc.
   The full module system
   Array slicing, and array bounds checking
   RAII (yes, it can work without exceptions)
   scope(exit)
   Memory safety protections
   Interfacing with C++
   COM classes and C++ classes
   assert failures are directed to the C runtime library
   switch with strings
   final switch
   unittest
   printf format validation
https://dlang.org/spec/betterc.html

Re: Assorted Thoughts on Zig and Rust

#194

Post by murkt »

haberman wrote: post #163

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…

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

Re: Assorted Thoughts on Zig and Rust

#195

Post by cesarb »

kzrdude wrote: post #192
q3k wrote: post #79

Earlier quoted context omitted.

Yet, Go’s net/http client/servers are fully production ready. This can be done right. Being able to just use them without having to follow the newest trends in a language’s ecosystem is a huge cognitive burden off my mind.

That is great. Maybe I should ask, what is it that makes Python standard lib modules likely to end up like this? The list is pretty long.

The Python standard library is old. For instance, urllib.urlopen() already existed in Python 1.4 (the oldest I could quickly find docs for), which is from 1996. Things that were useful back then (like a built-in uuencode module) no longer make much sense as part of the standard library. And mistakes in the API of a standard library are hard to fix without breaking backwards compatibility, while a third-party module can, in the worst case, be discarded and replaced by a newer one.

Re: Assorted Thoughts on Zig and Rust

#196

Post by jonahx »

pron wrote: post #89
sacado2 wrote: post #68

Earlier quoted context omitted.

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.

Those are nice taglines, but while Rust is a safer C++ in the sense that it is a language that espouses C++'s design philosophy and has a similar feel to it, Zig is something new altogether. The only thing that makes it more similar to C than to C++ is that C is an extremely simple language, as is Zig, while C++ is an extremely complex language. But other than that, Zig is a low-level language that is its own family,…

> in the sense that it is a language that espouses C++'s design philosophy

Could you elaborate on this?

Re: Assorted Thoughts on Zig and Rust

#197

Post by pron »

Rusky wrote: post #177
pron wrote: post #70

Earlier quoted context omitted.

My impression was completely the opposite. I was very excited about Rust at first, especially the ownership system, but after a while I saw that it was a cleaned-up C++ with most of C++'s problems (one of the most complex programming languages in software history; very slow feedback loop). Zig, on the other hand, seems revolutionary and a complete rethinking, from the ground-up, of what low-level programming should b…

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 monumental, awe-inspiring shrine erected to worship at the altar of accidental complexity. I admire the technical achievement -- I never imagined accidental complexity could be given such spectacular prominence -- but having spent my share of time with both C++ and Ada, I'd like to look elsewhere. I don't know if Zig will do the job, but the vision it has for low-level development is so refreshing, radical and different from everything else I've seen in my >20 years of professional software development that I'd like to give it a chance before settling for an improved C++. Anyway, it's a matter of personal aesthetic preference.

Re: Assorted Thoughts on Zig and Rust

#198

Post by estebank »

k__ wrote: post #189
estebank wrote: post #188

Earlier quoted context omitted.

I honestly think this is a factor of prior experience. When I started using Rust my background was in OOP languages, so I also went through the exercise of fitting trait pegs into a class shaped holes and it was painful. But this doesn't mean that traits and ADTs and how they interact is harder to learn or understand than Objects with its inheritance, polymorphism, encapsulation and abstraction concepts, it just mean…

I did learn much about classes and interfaces in university, independent of language. But not much on traits and ADTs(?). Can you recommend some general learning resources on that?

I do not have any non-Rust resources off the top of my head, but I can give you some quickly looked up resources and enough phrases to search for that should help you in this endeavor.

ADTs are Abstract Data Types[1][2][3]:

> ADT is implementation independent. For example, it only describes what a data type List consists (data) and what are the operations it can perform, but it has no information about how the List is actually implemented.

In the context of Rust it means that the traits, structs and enums are ADTs, while the impls are Data Structures.

Having structs and enums be the way they are in Rust (simplistic and with little extensibility beyond implementing traits) is that pattern matching[4][5] and destructuring is cheap and built in. Pattern matching becomes specially useful when combined with sum types/tagged unions/enums[6][7][8]. On the other corner you have Scala which lets you implement specific interfaces to allow structuring and destructuring for arbitrary types, but that has the same problems as overriding constructors in C++: the performance implications of pattern matching is impl dependent and hidden at the point of calling.

[1]: https://softwareengineering.stackexchange.com/questions/1487...

[2]: https://en.wikipedia.org/wiki/Abstract_data_type

[3]: https://abrickshort.wordpress.com/2005/03/06/abstract-data-t...

[4]: https://en.wikipedia.org/wiki/Pattern_matching

[5]: https://docs.scala-lang.org/tour/pattern-matching.html

[6]: https://www.schoolofhaskell.com/school/to-infinity-and-beyon...

[7]: https://chadaustin.me/2015/07/sum-types/

[8]: https://stackoverflow.com/questions/2502354/what-is-pattern-...

Re: Assorted Thoughts on Zig and Rust

#199

Post by fwsgonzo »

lzutao wrote: post #120
fwsgonzo wrote: post #84

Earlier quoted context omitted.

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 ?

no I think I tried just about everything: pub, extern etc.

The only thing that worked was adding a linker argumment: "-C", "link_args=--undefined="

That will force the linker to assume it's referenced.

Re: Assorted Thoughts on Zig and Rust

#200

Post by blandflakes »

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…

Oof I dunno I'd categorize the Python module system as "makes no sense and I can never get it right" - I'm sure it's consistent but it doesn't feel approachable to me.
Post reply on HN