Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig, the Small Language

zserge.com

Post reply on HN
Print view View original

341–350 of 429 posts

Re: Zig, the Small Language

#341

Post by cztomsik »

pcwalton wrote: post #274
cztomsik wrote: post #204

Earlier quoted context omitted.

had the same problem, if you're just prototyping, it's easy to silence that with _ = someVar you get used to it after some time - much better than for example rust, where you have to figure out all the lifetimes, muts and generic traits before.

> you get used to it after some time - much better than for example rust, where you have to figure out all the lifetimes, muts and generic traits before. They aren't comparable. Everything you mentioned in Rust is necessary for typechecking. Unused variable lints aren't necessary for anything.

I understand why is that needed.

I am saying that prototyping (for me) is much easier in Zig. Some people like to define all the types (and traits) first, if it works for them then it's ok. I like to get feedback on something working as soon as possible because I'm likely a bit wrong and I will need to refine or rethink the whole thing again, rust is putting obstacles in my way, Zig is not.

Re: Zig, the Small Language

#342

Post by user45 »

pcwalton wrote: post #292
azakai wrote: post #291

Earlier quoted context omitted.

> Moreover, we shouldn't assume that Zig pointers are the only feature that breaks spatial memory safety. It was simply the first one I found after like 2 minutes of looking through the docs. After like 5 more minutes I found another: extern unions. Just now I found another: sentinel-terminated pointers, since you could delete the sentinel. You're right on each of those points. But (AFAIK) all those types are explici…

Well, let's turn this around. Is C++ spatially memory safe? C++20 has slices (ranges). They're bounds checked, via the .at() method. You can get the integer overflow semantics of Zig with "-fsanitize=signed-integer-overflow -fsanitize=unsigned-integer-overflow -fsanitize=float-cast-overflow". You could write a checker that enforces that only these features are used (in fact, this checker basically exists--ISO Core C+…

Note that STL containers allow you to bounds check "[]" indexing even in release mode if you set the right preprocessor directives. The flag differs between compilers and stdlib implementations, though. For libstdc++ (default on linux), use _GLIBCXX_ASSERTIONS. For example, the following code aborts on release builds too:

  // g++ -O3 -D_GLIBCXX_ASSERTIONS=1 file.cpp
  #include 
  #include 

  int main() {
    std::vector vec{1, 2, 3, 4};
    std::cout
MSVC provides similar functionality using the _ITERATOR_DEBUG_LEVEL directive. The point is that there is no inherent limitation that one has to use the .at() method for bounds checking STL container access.

Re: Zig, the Small Language

#343

Post by xmonkee »

tialaramex wrote: post #317
brundolf wrote: post #297

It just occurred to me, Zig could be a great learning-language for CS When I was in college we mostly used C++, which exposed (and thereby taught) a lot of core concepts around how computers and low-level languages work. But it was also a bit of a nightmare for... unrelated, obvious reasons. Rust is great for building software, but as a learning language I think it introduces too many additional concepts, has too man…

I still think the first language when I was an undergraduate (so, last century) was the correct choice: an ML in our case SML/NJ The stuff about how this actually works can come later, we're not teaching electronics students here (or are we? Zig as first language for electronics students makes some sense) I agree that (safe) Rust has too much stuff for a first language for Computer Scientists. Lifetimes! Polymorphism…

SML/NJ is an absolutely marvelous first language. You will learn to think in abstractions and not get bogged down in any implementation details. The downside is that you will be amazed at the lack of union types and pattern matching in almost all mainstream languages you learn later.

Re: Zig, the Small Language

#344

Post by cztomsik »

mwcampbell wrote: post #277
cztomsik wrote: post #198

Earlier quoted context omitted.

for native addons for GC'd languages you probably don't want to introduce another GC, rust is not well-suited for interfacing with FFI, C++ is a bit heavyweight but okish I guess and C is totally unsafe, Zig is just right.

> rust is not well-suited for interfacing with FFI How so? Packages like neon [1] and rustler [2] suggest otherwise. I'm using both of those in a real product (I'm using neon directly, to write native modules for an Electron app; on the back-end, I depend on an Elixir package that uses rustler). [1]: https://github.com/neon-bindings/neon [2]: https://github.com/rusterlium/rustler

I admit it's a long time since I've been using neon so things might have changed but at the time I had a feeling that the whole thing is very fragile and not really safer than if I was using pointers directly.

Especially, if you callback into JS and that calls back to native then I think you don't have any guarantees from rust anymore (aka you are being lied) because compiler cannot not know about that.

Also builds were a bit tricky, it needed node.js headers in proper place, etc. In zig you just include napi.h because zig can import C including macros and everything. Or if you need to call glfw/nanovg/stb/xxx you just @cImport() and it works.

Zig also supports C-style strings in a better way and I can't recall all of the obstacles right now but I'm way way more productive with Zig after 1 month than I was with rust after 5ys.

Re: Zig, the Small Language

#345

Post by cztomsik »

pcwalton wrote: post #276
cztomsik wrote: post #198

Earlier quoted context omitted.

for native addons for GC'd languages you probably don't want to introduce another GC, rust is not well-suited for interfacing with FFI, C++ is a bit heavyweight but okish I guess and C is totally unsafe, Zig is just right.

> rust is not well-suited for interfacing with FFI That's a surprising comment, given the massive deployments of hybrid Rust/C++ apps at huge scale that exist! Does Zig have any equivalent to cxx for interfacing with C++ code?

you are right about cxx, I made this comment with C FFI in mind. and for that, Zig couldn't have better integration.

AFAIK there is no simple way to interface with C++ from Zig, you either have C headers or you write a bit of C++ to export what you need and then you're back in the game.

Or you flip it on its head and use zig as C++ compiler and call your zig-parts from C++ but I have no experience with this, I think bun does this.

Re: Zig, the Small Language

#346

Post by Gibbon1 »

TakeBlaster16 wrote: post #65
masklinn wrote: post #22

Earlier quoted context omitted.

> I do understand the reasoning (they don't want people committing poor quality code) Not that this lint actually achieves that, or even prevents real errors. Go has the same, and it's so simplistic as to only be annoying. For instance not sure whether this fails in Zig but Go will allow this: v1, err := Foo() if err != nil { return nil, err } v2, err := Bar(v1) return v2, nil Error of second call is never checked, b…

Zig seems to behave similarly. This compiles: export fn x() i32 { var a: i32 = 1; // okay a = 2; return a; } This does not: export fn x() i32 { var a: i32 = 1; // unused variable var a2: i32 = 2; return a2; } > Not that this lint actually achieves that, or even prevents real errors. I have to agree. If there's one thing I've learned over the years, it's that you can't prevent bad code by enforcing lint errors.

Zig will also let you return references to stack allocated objects.

Re: Zig, the Small Language

#347

Post by williamstein »

beltsazar wrote: post #124

Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

zig is not meant to be just a systems programming language. It's stated goal is "Zig is a general-purpose programming language and toolchain for maintaining robust, optimal and reusable software." and Andrew really does intend for it to be useful far beyond systems programming. I hope they succeed, since I've been using zig regularly for over a year now, and I love it. I have decades of experience with assembly, Fortran, C, C++, Python, and Javascript, and I really appreciate what the Zig developers are trying to do. I hope they succeed!

Re: Zig, the Small Language

#348

Post by pwdisswordfish9 »

WalterBright wrote: post #158
oconnor663 wrote: post #140

Earlier quoted context omitted.

> every compiler switch is a bug I totally get where this is coming from, but on the other hand it seems like Rust and Zig both get a lot of value from having the compiler understand the difference between debug and release modes, and it seems like modern C++ suffers somewhat from not having any built-in way to do something similar. The optimal number of compiler switches might not be zero.

D literally has the switches `-release` and `-debug`.

Why don’t you fix those bugs?

Re: Zig, the Small Language

#349

Post by pjmlp »

tialaramex wrote: post #317
brundolf wrote: post #297

It just occurred to me, Zig could be a great learning-language for CS When I was in college we mostly used C++, which exposed (and thereby taught) a lot of core concepts around how computers and low-level languages work. But it was also a bit of a nightmare for... unrelated, obvious reasons. Rust is great for building software, but as a learning language I think it introduces too many additional concepts, has too man…

I still think the first language when I was an undergraduate (so, last century) was the correct choice: an ML in our case SML/NJ The stuff about how this actually works can come later, we're not teaching electronics students here (or are we? Zig as first language for electronics students makes some sense) I agree that (safe) Rust has too much stuff for a first language for Computer Scientists. Lifetimes! Polymorphism…

Actually my software engineering degree had plenty of overlap with electronics content.

Re: Zig, the Small Language

#350

Post by pjmlp »

stjohnswarts wrote: post #322
brundolf wrote: post #297

It just occurred to me, Zig could be a great learning-language for CS When I was in college we mostly used C++, which exposed (and thereby taught) a lot of core concepts around how computers and low-level languages work. But it was also a bit of a nightmare for... unrelated, obvious reasons. Rust is great for building software, but as a learning language I think it introduces too many additional concepts, has too man…

Modern c++ needn't be "low level" particularly with c++20 and up, just sayin' . Back when I start school sure RAII was radical and "high level" and everything else was pretty low level. Modern C++ is a different creature. Anyway. I think small languages like c and zig are great for learning as a first language especially for computer engineering students. I still think that a lisp is the best first language for CS st…

Radical only for those entreched into the ways of C, our university was already teaching RAII to first year students in 1994.

First semester was Pascal, followed by C++ on the second one.

Post reply on HN