An intro to Zig's integer casting for C programmers • Hacker News Board

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

#131

Post by johnisgood » Thu, May 13, 2021, 1:02 AM UTC

c-cube wrote: post #129

johnisgood wrote: post #107

Earlier quoted context omitted.

My opinion: I really dislike Rust's syntax because to me it is similar to Perl's that I also do not like that much as I do not know what is happening just by looking at it (I still like to use Perl here and there, but these days I lean towards Tcl more), it seems hidden from me, even compared to something as C where I have to think about conversions and whatnot. I can easily read and understand someone's Ada, C, or O…

Thank you for the answer :-). I'm still surprised because to me, Rust looks a _lot_ like OCaml with curly braces. The surface lexical conventions are mixed with C++ (like `::` for namespacing) but code still looks more like OCaml than C, with `let` bindings, sum types, expressions, `match` being omnipresent. Even the type annotations look more ML-ish than the type-first C convention. I fail to see the relation to per…

I compared it to Perl because of its heavy use of symbols in general. In Rust, you can have 6 symbols next to each other and that is valid code. See below.

OCaml does not look like Rust to me (OCaml seems more consistent, and Rust seems like a mixed bag of everything to me). It does not hide as much behind symbols for example as Rust does, I think, and learning it was really easy. I tried to read Rust, I really did, but everything is so hidden from me. I did not mean to say that any of the mentioned languages are anywhere close to C though. In any case, if I had to look at reference implementations, C would be the best (to me). It is really easy to know what is going on and why, and thus it is easy to implement it in any languages I know. Probably because it is not a language with many high-level abstractions or language constructs (syntactic sugars) that hide what is going on.

Example snippets as to why I dislike Rust:

  let mut parents_array = ArrayVec::::new()

  let input_ptrs: &[*const u8; DEGREE] = &*(inputs.as_ptr() as *const [*const u8; DEGREE]);

And this is nothing, there are much worse ones, and I would have to give you files for that, but pretty much any famous Rust project is difficult to read for me. I really do not understand most Rust code, I wonder if the problem is with me.

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

#132

Post by johnisgood » Thu, May 13, 2021, 6:12 AM UTC

mousepilot wrote: post #124

johnisgood wrote: post #112

Earlier quoted context omitted.

It has been a while, but you may want to look at: - https://en.wikibooks.org/wiki/Ada_Programming/Libraries/GNAT... (search for "C select()") - https://www.codelabs.ch/anet/ - https://github.com/samueltardieu/adasockets - https://github.com/rtyler/ada-playground/blob/master/epollec... Some old reading: https://brokenco.de/2013/04/07/async-with-ada.html You may want to check how GNAT.Sockets and Anet are implemented,…

thanks man, your post is a great timesaver, that wikibooks link itself is packed with info!

Of course, you are welcome!

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

#133

Post by nyberg » Sat, May 15, 2021, 5:18 PM UTC

scoutt wrote: post #123

Kolja wrote: post #120

Earlier quoted context omitted.

> I am curious to know the reasons behind the @as() syntax. What's wrong with "i32 y = (i32) x;"? Built-ins in Zig are functions beginning with `@`. Your cast operator would be a new syntax construct, something Zig tries to limit as much as possible (keeping the parser simple). > What type is "b"? i32? That's easy, i32. Integer literals are of type comptime_int, which may coerce into other integer types if possible w…

> That's easy. For code that is not yours, or code that you open a year later, I think it's easier to specify the type. Exactly as when you see something like "var x = some_function();" and you need to know the type.

You can also use `@compileLog(@TypeOf(some_function))` or the same for the result. Type inference mostly makes it easier to change the types involved without having to update every single variable binding which would often be rather error prone in languages with implicit casts.

The other gain here is with duck-typing as being less explicit allows you to write more generic code which will often do what you want as long as the shape fits without `void*` which gives up on type safety.

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

#134

Post by lionkor » Thu, May 20, 2021, 8:29 AM UTC

AnIdiotOnTheNet wrote: post #6

lionkor wrote: post #2

> If runtime safety is turned off, you get undefined behavior You already know someone will teach their students to always have it off because its "slower" or something. Make something idiot-proof and the world invents a better idiot. Another language that does safety like this incredibly well is Ada (Ada/SPARK), and I'm unsure why people aren't more hyped about it. So many people hype Rust or Zig or whatever new lan…

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

In my mind this isn't about safety scissors at all. I hate languages that in any way limit the kind of code I want to write, which is why I write C++ for the most part, but that's another rant for another day.

If you dont want full control like in C++, a language would be nice that has one specific style, one specific way to do things, and so on. Go(lang) is quite close to this, in my experience. You can't do thread safety wrong, because there's only really one way, and so on.

I would love a language with

1. Explicit nullable types (not like Java's "anything can be null" design), so everything is a non-nullable reference type unless its "optional" for example. I strongly support the idea of a nullable type only being used where it being null carries information.

2. Strong typing - like, tungsten strong. Implicit conversions need to be compiler errors, no implicit constructors, etc. with simple explicit casting

3. One style - and it better not be Java-like forced-OOP.

4. Full and clear memory control, RAII support, no gc. I need my RAM for other stuff.

I'm not sure if there's a language like that out there. I don't care for library support, I just want a fun language.

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

#135

Post by nobodywasishere » Fri, May 21, 2021, 4:38 PM UTC

greatgoat420 wrote: post #40

nobodywasishere wrote: post #26

Earlier quoted context omitted.

There's an Ada compiler as part of gcc. The most prominent project that i know of written in ada is ghdl.

There was at least always the recommendation to only use the version of the Ada compiler released by the FSF as the regular GCC one is/was more encumbered.

Are they not the same thing?

https://en.wikipedia.org/wiki/GNAT