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

Zig's Lovely Syntax

matklad.github.io

Post reply on HN
Print view View original

211–220 of 246 posts

Re: Zig's Lovely Syntax

#211

Post by brabel »

WalterBright wrote: post #202
brabel wrote: post #93

Earlier quoted context omitted.

I think this is not equivalent because in D, this imports all symbols in the package `std` while in Zig, you just get a "struct" called `std`. I think the equivalent D is: import std=std;

What I wrote is equivalent to the zig declaration. Google says: const my_module = @import("my_module.zig"); This allows you to access pub (public) declarations from my_module.zig through the my_module identifier.

Yes, but how is that equivalent?

Zig:

    const std = @import("std");
    pub fn main() !void {
      // std is like a namespace here
      std.debug.print("Hello, World!\n", .{});
    }
D:

    import std.stdio;
    void main()
    {
      // no namespace here, "writeln" and everything else in "std.stdio" is imported
      writeln("Hello, World!");
    }
The closest to Zig in D would be:

    import io = std.stdio;
    void main()
    {
      io.writeln("Hello, World!");
    }

Re: Zig's Lovely Syntax

#212

Post by brabel »

dpassens wrote: post #161
brabel wrote: post #123

Earlier quoted context omitted.

The Zig code returns any `type`, it's impossible to say what that is without looking at the implementation. It can be different types completely depending on the comptime arguments. But I agree it probably returns a struct type. Assuming that's the case, you're right and the equivalent would be: Zig: fn ArrayListType(comptime T: type) type { D: ArrayList!T ArrayListType(T)() { But now the D version is more specific a…

No, you misunderstand. The function doesn't return any type, it returns _a_ type. Types are values in Zig and returning them from function is how generics are implemented.

I know how Zig works. `type` is some type the function will return, you must look at the implementation to know what actually got returned, given the comptime arguments given to it by the caller (as I already mentioned). Where is the misunderstanding??

Re: Zig's Lovely Syntax

#213

Post by brabel »

johnisgood wrote: post #164
brabel wrote: post #108

Earlier quoted context omitted.

> On large projects its still cheaper and faster to grep from the CLI than to use Intellij IDE search. Esp if you wish to restrict search to subsets of dirs. You must never have used Intellij to say that... it hurts me to hear this. If I catch a developer "grepping" for some type in the CLI, I will sit down with them for a few hours explaining how to use an IDE and how grep is just dumb text search without any of the…

He said cheaper and faster. It takes 5-10 minutes for IntelliJ to start up properly for me, and doing anything in it is just too slow. (rip)grep is way faster. Yes yes, I need a better PC. (rip)grep would still be faster, however, but I would use the IDE.

Normally, the IDE is open at all times when you're coding. But if you don't code all the time, I can see how you may prefer to avoid IntelliJ and I would also do that if I was just searching for strings.

Re: Zig's Lovely Syntax

#214

Post by pjmlp »

minitech wrote: post #207
pjmlp wrote: post #206

Earlier quoted context omitted.

For starters being text based for what is supposed to be a systems language, that should support binary distribution.

Supporting binary distribution seems unrelated to the ways in which it’s “like JavaScript’s CJS”, especially in the context of this post about syntax.

Not really, because I expect to also have binary distribution of modules, as in systems languages like Modula-2, Mesa, Object Pascal/Turbo/Delphi, D, Ada,....

Re: Zig's Lovely Syntax

#215

Post by WalterBright »

brabel wrote: post #211
WalterBright wrote: post #202

Earlier quoted context omitted.

What I wrote is equivalent to the zig declaration. Google says: const my_module = @import("my_module.zig"); This allows you to access pub (public) declarations from my_module.zig through the my_module identifier.

Yes, but how is that equivalent? Zig: const std = @import("std"); pub fn main() !void { // std is like a namespace here std.debug.print("Hello, World!\n", .{}); } D: import std.stdio; void main() { // no namespace here, "writeln" and everything else in "std.stdio" is imported writeln("Hello, World!"); } The closest to Zig in D would be: import io = std.stdio; void main() { io.writeln("Hello, World!"); }

You can write in D:

    std.stdio.writeln("Hello, world!");

Re: Zig's Lovely Syntax

#216

Post by flohofwoe »

tialaramex wrote: post #165
flohofwoe wrote: post #9

Earlier quoted context omitted.

The dot is just a placeholder for an inferred type, and IMHO that makes a lot of sense. E.g. you can either write this: const p = Point{ .x = 123, .y = 234 }; ...or this: const p: Point = .{ .x = 123, .y = 234 }; When calling a function which expects a Point you can omit the verbose type: takePoint(.{ .x = 123, .y = 234 }); In Rust I need to explicitly write the type: takePoint(Point{ x: 123, y: 234); ...and in neste…

Because we've said x is a constant we're obliged to specify its type. For variables we're allowed to use inference and in most cases the type can be correctly inferred, but for constants or function signatures inference is deliberately prohibited. const x: Rect = .... [Note that in Zig what you've written isn't a constant, Zig takes the same attitude as C and C++ of using const to indicate an immutable rather than a…

> Zig takes the same attitude as C and C++ of using const to indicate an immutable rather than a constant

I think it's a bit more complicated than that: AFAIK Zig consts without explicit type may be comptime_int or comptime_float, and those don't exist at runtime. Only consts with an explicit type annotation are 'runtime consts'.

Also see:

https://www.godbolt.org/z/esTr463bT

...still, I think Rust should allow to infer the type at least inside struct initialization, it would make designated init code like this a lot less noisy (Zig would suffer from the same problem if it hadn't the .{} syntax):

https://github.com/floooh/sokol-rust/blob/main/examples/texc...

...C99 is still the 'benchmark' when it comes to struct initialization:

https://github.com/floooh/sokol-samples/blob/29d5e9f4a56ae18...

Re: Zig's Lovely Syntax

#217

Post by wolvesechoes »

So Zig is a new darling, eh?

I sometimes have an impression that the main purpose of all these new languages is to write blog posts about them. Even if they call themselves general-purpose, they are mostly blog-purpose.

Re: Zig's Lovely Syntax

#218

Post by tialaramex »

flohofwoe wrote: post #216
tialaramex wrote: post #165

Earlier quoted context omitted.

Because we've said x is a constant we're obliged to specify its type. For variables we're allowed to use inference and in most cases the type can be correctly inferred, but for constants or function signatures inference is deliberately prohibited. const x: Rect = .... [Note that in Zig what you've written isn't a constant, Zig takes the same attitude as C and C++ of using const to indicate an immutable rather than a…

> Zig takes the same attitude as C and C++ of using const to indicate an immutable rather than a constant I think it's a bit more complicated than that: AFAIK Zig consts without explicit type may be comptime_int or comptime_float, and those don't exist at runtime. Only consts with an explicit type annotation are 'runtime consts'. Also see: https://www.godbolt.org/z/esTr463bT ...still, I think Rust should allow to inf…

Surely Rust can infer the type in your example? It just doesn't provide Zig's syntax to use the inferred type to manually initialize. If you wrote some_fn() here where some_fn's return type was genericised, Rust would ask for the appropriately typed some_fn not say it doesn't know the type.

Re: Zig's Lovely Syntax

#219

Post by johnisgood »

brabel wrote: post #213
johnisgood wrote: post #164

Earlier quoted context omitted.

He said cheaper and faster. It takes 5-10 minutes for IntelliJ to start up properly for me, and doing anything in it is just too slow. (rip)grep is way faster. Yes yes, I need a better PC. (rip)grep would still be faster, however, but I would use the IDE.

Normally, the IDE is open at all times when you're coding. But if you don't code all the time, I can see how you may prefer to avoid IntelliJ and I would also do that if I was just searching for strings.

IntelliJ is unfortunately very sluggish for me either way, and as of now, if it is open, I cannot do anything else on the PC, which means it is only open when I am actively coding, but even then, it is just so slow that I would rather not.

On the other hand, VSCodium and vim / emacs are always open, at the same time. But I do not like coding in Java / Kotlin without IntelliJ, which I do for some work.

Honestly, a better PC would solve this issue.

Re: Zig's Lovely Syntax

#220

Post by cyber1 »

At first glance, when I looked through the Zig reference, I didn’t like a lot about its syntax (though syntax isn’t the most important thing for me). But when I tried writing in it, I changed my mind - it’s a concise and convenient language with a very low entry barrier. It feels like Go, and with some C experience, you can quickly start writing functional stuff.
Post reply on HN