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

An intro to Zig's integer casting for C programmers

lagerdata.com

Post reply on HN
Print view View original

81–90 of 135 posts

Re: An intro to Zig's integer casting for C programmers

#81

Post by tomp »

scoutt wrote: post #58

I am curious to know the reasons behind the @as() syntax. What's wrong with "i32 y = (i32) x;"? I look with interest to new languages but after so many years dealing with C, my parser crashes when I see the type after the variable name and at the end of functions declarations. var x : u8 = 5; What's wrong with "u8 x = 5;"? And I don't really like type inference very much (or when it's abused or cannot be avoided). Wh…

juxtaposition (i.e. syntax that has meaning when two identifiers stand together separated only by whitespace) is generally a problem for parsing. Basically, it introduces all kinds of parsing ambiguities. Compare the following:

    a *b
    a * b
    a[n] x
    b [n]
    a y
    a  y
    e(1) f
    e (1)f
Even for C/C++ this is complicated (you need the symbol table when parsing, to know if an identifier is a type or not), but for more advanced languages, it's even worse (e.g. if you support pattern matching / destructuring assignment).

Declaring variables with var let's you also write let or const instead, giving the programmer more options (and making those options obvious as well).

You might not "like" type inference, but it really is superior to no-type-inference - you can always also write the expected type, if you want.

Re: An intro to Zig's integer casting for C programmers

#82

Post by Shadonototro »

losvedir wrote: post #75
Shadonototro wrote: post #65

casting, one of the reason i gave up with Zig quickly, it just is painful and solves nothing, it makes the code hard to decipher

How quickly? Like, you saw it in the docs when you were mildly interested and decided it wasn't for you? Or you started a project, had at least a "hello world" compiling, but then eventually gave up on it because you were tired of casting? In that case I'm curious what the project was since I haven't run into casting all that often, but it might vary by domain.

It was a while ago, a game engine, it just feels bad, maybe i misused the language, but that is a sign things aren't intuitive

Some people love typing code like they'd write books, i don't, i like to be concise and to go straight to the point

And it's not just as(i32) intToFloat(f32) floatToInt(i32), and then between i8 i32 i64, and then bitwise operations, and then slices, and then C strings etc etc etc, lot of visual bloat

Re: An intro to Zig's integer casting for C programmers

#83

Post by Someone »

dnautics wrote: post #67
scoutt wrote: post #58

I am curious to know the reasons behind the @as() syntax. What's wrong with "i32 y = (i32) x;"? I look with interest to new languages but after so many years dealing with C, my parser crashes when I see the type after the variable name and at the end of functions declarations. var x : u8 = 5; What's wrong with "u8 x = 5;"? And I don't really like type inference very much (or when it's abused or cannot be avoided). Wh…

> What's wrong with "u8 x = 5;"? I believe it makes the parser marginally more complicated. Let's say you had a non-builtin type, "foo". The var trigger immediately declares what's going on. For "foo x = 5;" the parser must either 1) have contextual information that foo is a declared type or 2) wait to notice that there are two identifiers side-by-side and then resolve that this means "it must be a variable declarati…

A bit more than marginally more complicated, if you consider the cases of parsing partial or incorrect programs.

You want to be able to (somewhat) parse those so that you can syntax-colour, auto-complete, and mark errors in a code editor.

I think those are the major reasons modern languages don’t do such things the C way.

Re: An intro to Zig's integer casting for C programmers

#84

Post by june11 »

TchoBeer wrote: post #44
AnIdiotOnTheNet wrote: post #6

Earlier quoted context omitted.

> Make something idiot-proof and the world invents a better idiot. Sure, but if you only ever give people safety scissors then you're severely limiting the kinds of things that they can build. You have to let people who know what they are doing be able to do what they need to do, so you have to be able to turn the runtime safety off. Zig can do this at the scope level.

I don't understand why there aren't any solutions like this. Why aren't there any languages with a good garbage collector but also let you turn it off and work with memory manually. Maybe there is and I don't know of it? Maybe garbage collected languages and manual memory languages require different design? I don't know.

dlang has exactly this, with both marking functions as @nogc and being able to both use the gc in one block, and malloc free in the next. You can also limit D a subset called 'BetterC'. I Really enjoy being able to gc my way though a problem until I need some explicit memory structure for putting together a ECS or similar memory management heavy patterns.

Re: An intro to Zig's integer casting for C programmers

#85

Post by c-cube »

johnisgood wrote: post #53
gilnaa wrote: post #10

Earlier quoted context omitted.

Not to sound too aggressive, I'm not sure why ada programmers keep being surprised at the hype. Safety (of all kinds) is not the only selling point of Rust and Zig, and the fact that Ada also have safety measures doesn't mean that it's instantly an option for me. For example, I keep seeing people hype about Zig/Rust, for all kinds of reasons; and the way that they present their arguments is very compelling. While I'v…

> I don't like Rust because it gives me memory safety, tons of languages do that. I love Rust because the tradeoffs it gives me worth the switch, and the overall tooling and ecosystem are very well made. Same applies to the tooling of Ada/SPARK, but as you have said, it is pretty much a PR issue.

I'm not saying it's justified, but I think the syntax is also a big impediment (just like for my daily driver, OCaml). Ada looks pretty verbose and annoying to write code in, at least if one wants to use it for side projects, small utilities, etc. rather than spaceship firmware; and that's probably how a lot of languages become popular, you need to tinker with them on small things.

OCaml has seen the alternative "Reason" syntax (JS-like) grow in popularity. Maybe a C-like (or better, rust-like) syntax for Ada would help the language's adoption. People already using Ada would complain that the current syntax is fine but they're not the target demographic :-)

Re: An intro to Zig's integer casting for C programmers

#86

Post by MaxBarraclough »

ModernMech wrote: post #63
roblabla wrote: post #41

Earlier quoted context omitted.

Not sure why you think ADA/Spark isn't free. There's GNAT[0], an open source ADA compiler that's part of the GNU toolchain, a fairly good book teaching ADA and SPARK[1] by Ada Core, and plenty of tutorials. Accessibility is really not the problem. The problem is, Ada is an old language that has many similar problems to C: lack of a good package management story, and a design by committee making language evolution gla…

Your first link pretty much says it all: barebones website 5 years out of date, no docs, no resources, no community links, no indication that this project is even alive. To top it off the project is named after one of the most annoying creatures on the face of the Earth. This is a marketing issue. The problem for older languages is that the bar for what's expected of a language has risen substantially. A long time ag…

> Your first link pretty much says it all: barebones website 5 years out of date, no docs, no resources, no community links, no indication that this project is even alive.

A better starting point might be http://www.GetAdaNow.com/

Re: An intro to Zig's integer casting for C programmers

#87

Post by layer8 »

tomp wrote: post #81
scoutt wrote: post #58

I am curious to know the reasons behind the @as() syntax. What's wrong with "i32 y = (i32) x;"? I look with interest to new languages but after so many years dealing with C, my parser crashes when I see the type after the variable name and at the end of functions declarations. var x : u8 = 5; What's wrong with "u8 x = 5;"? And I don't really like type inference very much (or when it's abused or cannot be avoided). Wh…

juxtaposition (i.e. syntax that has meaning when two identifiers stand together separated only by whitespace) is generally a problem for parsing. Basically, it introduces all kinds of parsing ambiguities. Compare the following: a *b a * b a[n] x b [n] a y a y e(1) f e (1)f Even for C/C++ this is complicated (you need the symbol table when parsing, to know if an identifier is a type or not), but for more advanced lang…

> you can always also write the expected type, if you want.

But you have to read the code of people who didn‘t.

Re: An intro to Zig's integer casting for C programmers

#88

Post by AnIdiotOnTheNet »

Shadonototro wrote: post #65

casting, one of the reason i gave up with Zig quickly, it just is painful and solves nothing, it makes the code hard to decipher

I like it because it provides explicitness and readability. There is no guessing or following a flow chart of implicit type conversions to see what's going on.

Re: An intro to Zig's integer casting for C programmers

#89

Post by jstimpfle »

joppy wrote: post #68
pornel wrote: post #29

Earlier quoted context omitted.

Rust does go overboard though, e.g. indexing requires `usize`. You either use `usize` for all your integers, or you end up with a cast-salad. arr[i as usize] This is actually risky, because even when you only meant to extend, you can also accidentally truncate or change sign. `as` does all of these things without a warning, and mixed with type inference it can easily lead to surprises. Rust makes it worse by insistin…

The Rust approach of having all indexing being unsigned has been extremely annoying for programming algorithms which need to do interesting indexing patterns like walking backwards through an array while indexing into another: the fact that “i >= 0” can no longer be used as a loop condition is quite exasperating. It means other more complicated indexing or looping approaches need to be used, and when showing code to…

negative indexing could even make sense in some situations. It's not at a far stretch to imagine a pointer pointing to the one-past-last element of a series, and use e.g. -1 to get the most recent element. Python's indexing indeed works like that way.

Re: An intro to Zig's integer casting for C programmers

#90

Post by Narishma »

TchoBeer wrote: post #44
AnIdiotOnTheNet wrote: post #6

Earlier quoted context omitted.

> Make something idiot-proof and the world invents a better idiot. Sure, but if you only ever give people safety scissors then you're severely limiting the kinds of things that they can build. You have to let people who know what they are doing be able to do what they need to do, so you have to be able to turn the runtime safety off. Zig can do this at the scope level.

I don't understand why there aren't any solutions like this. Why aren't there any languages with a good garbage collector but also let you turn it off and work with memory manually. Maybe there is and I don't know of it? Maybe garbage collected languages and manual memory languages require different design? I don't know.

I think this will just lead to a split ecosystem with some libraries requiring a GC and others requiring manual memory management.
Post reply on HN