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

221–230 of 246 posts

Re: Zig's Lovely Syntax

#221

Post by ivanjermakov »

NobodyNada wrote: post #192
ivanjermakov wrote: post #191

Earlier quoted context omitted.

Right, but there is not much semantic difference in having one or having zero allowed values.

There's a huge semantic difference: a type with zero allowed values can never be constructed. This means that a function that returns an uninhabited type is statically known to not return -- since there's no way it could construct an uninhabited value for a return expression. It also means you can coerce a value of uninhabited type into any other type, because any code which recieves a value of an uninhabited type mu…

We were talking about `void`, not `!`. It's clear that "never" type has a special language support. Difference between `void` and `()` is much less subtle.

Re: Zig's Lovely Syntax

#222

Post by flohofwoe »

tialaramex wrote: post #218
flohofwoe wrote: post #216

Earlier quoted context omitted.

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

> Surely Rust can infer the type in your example?

Well in Rust code like this:

    pass_action.colors[0] = sg::ColorAttachmentAction {
        load_action: sg::LoadAction::Clear,
        clear_value: sg::Color { r: 0.25, g: 0.5, b: 0.75, a: 1.0 },
        ..Default::default()
    };
...I cannot write:

    pass_action.colors[0] = {
        load_action: sg::LoadAction::Clear,
        clear_value: { r: 0.25, g: 0.5, b: 0.75, a: 1.0 },
        ..Default::default()
    };
...even though the Rust compiler has all the type information it needs (from the 'left-hand-side').

For comparison, in Zig it would look like this:

    pass_action.colors[0] = .{
        .load_action = .Clear,
        .clear_value = .{ .r=0.25, .g=0.5, .b=0.75, .a=1.0 },
    };
...Zig is still only halfway there compared to C99 (e.g. Zig doesn't allow designator chaining and is much less flexible for initializing nested arrays - in those areas it's closer to Rust than C).

Re: Zig's Lovely Syntax

#223

Post by [deleted] »

hinkley wrote: post #92
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…

Thanks for the explanation, but I don’t think you’ve sold me on .x Think I’d rather do the Point{} syntax.

[deleted]

Re: Zig's Lovely Syntax

#224

Post by zem »

z_open wrote: post #54

> Raw or multiline strings are spelled like this: const still_raw = \\const raw = \\ \\Roses are red \\ \\ Violets are blue, \\ \\Sugar is sweet \\ \\ And so are you. \\ \\ \\; \\ ; This syntax seems fairly insane to me.

that was my favourite bit in the entire post - the one place where zig has unambiguously one-upped other languages. the problems it is solving are:

1. from the user's point of view, you can now have multiline string literals that are properly indented based on their surrounding source code, without the leading spaces being treated as part of the string

2. from an implementation point of view having them parsed as individual lines is very elegant, it makes newline characters in the code unambiguous and context independent. they always break up tokens in the code, regardless of whether they are in a string literal or not.

Re: Zig's Lovely Syntax

#225

Post by tialaramex »

flohofwoe wrote: post #222
tialaramex wrote: post #218

Earlier quoted context omitted.

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.

> Surely Rust can infer the type in your example? Well in Rust code like this: pass_action.colors[0] = sg::ColorAttachmentAction { load_action: sg::LoadAction::Clear, clear_value: sg::Color { r: 0.25, g: 0.5, b: 0.75, a: 1.0 }, ..Default::default() }; ...I cannot write: pass_action.colors[0] = { load_action: sg::LoadAction::Clear, clear_value: { r: 0.25, g: 0.5, b: 0.75, a: 1.0 }, ..Default::default() }; ...even thou…

Right but your call to Default::default() gives the game away that we do have inference. Default::default() is generic, if we didn't have inference we'd need to tell it which of the enormous number of implementations of that trait it should call.

Would you take syntax like clear_value: _ { r: 0.25, g: 0.5, g: 0.75, a: 1.0 } ?? Then we're saying that we know we need to pick a type here but the type can be inferred where our underscore was, just like when we

let words: Vec = "A sentence broken by spaces".split_whitespace().collect();

Re: Zig's Lovely Syntax

#226

Post by brabel »

johnisgood wrote: post #219
brabel wrote: post #213

Earlier quoted context omitted.

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

I completely understand. But I suppose most developers, specially in the USA (where salaries are astronomicals) and even Europe (where I am, most top-of-the-line laptops are affordable to most devs here) it's not a problem, but I too have a low-end Mac (which would be an expensive machine in some countries!) where IntelliJ doesn't run so well, as you mention. In those cases, I use emacs which has similar "grep" functionality. What I was arguing against was just doing it "only" in the CLI. You will spend hours for something that should be minutes!! But even the guy who originally said he does it on the CLI admited he's actually just calling it from the CLI, but using an IDE (if you allow me to call Neovim an IDE) to go through the results... which is basically the poor man way to do what IntelliJ does (no offence meant).

Re: Zig's Lovely Syntax

#227

Post by qcnguy »

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.

It sounds totally broken. IntelliJ starts in a few seconds for me. 10 minutes is crazy, maybe your system has no free RAM at all when you try that.

Re: Zig's Lovely Syntax

#228

Post by johnisgood »

qcnguy wrote: post #227
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.

It sounds totally broken. IntelliJ starts in a few seconds for me. 10 minutes is crazy, maybe your system has no free RAM at all when you try that.

I have 8 GB only, so yeah, no RAM when I have a browser open. And by startup I am referring to background indexing, project initialization, etc. on a large enough codebase.

Re: Zig's Lovely Syntax

#229

Post by johnisgood »

brabel wrote: post #226
johnisgood wrote: post #219

Earlier quoted context omitted.

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

I completely understand. But I suppose most developers, specially in the USA (where salaries are astronomicals) and even Europe (where I am, most top-of-the-line laptops are affordable to most devs here) it's not a problem, but I too have a low-end Mac (which would be an expensive machine in some countries!) where IntelliJ doesn't run so well, as you mention. In those cases, I use emacs which has similar "grep" funct…

Thanks!

FWIW in VSCodium, I have one or more terminals open, and sometimes I would (rip)grep. Not always, but sometimes, when I see there is use for it. I am used to the quick output of the tool and sometimes that is all I need.

Re: Zig's Lovely Syntax

#230

Post by Tmpod »

qcnguy wrote: post #56

Weird the author finds it lovely and compares to Kotlin, but doesn't find Kotlin superior. Kotlin invested heavily in a really nice curly brace syntax. It is actually the nicest out there. In every point the author makes, it feels like Kotlin did it the same or better. For example: 1. Integer literals. "var a = 1" doesn't work, seems absurd. In Kotlin literals do have strong types, but coercion is allowed when defini…

> only downside is the trimming is done at runtime but that could easily be fixed without changing the language.

trimMargin and trimIndent (as well as other operations like concatenation) actually get handled at compile time if the string isn't interpolated.

Post reply on HN