/tech/ - Technology★

>>998889 (OP)

Hello World

const std = @import("std");

pub fn main() !void {
    // If this program is run without stdout attached, exit with an error.
    var stdout_file = try std.io.getStdOut();
    // If this program encounters pipe failure when printing to stdout, exit
    // with an error.
    try stdout_file.write("Hello, world!\n");
}

But typically you don't want to just print to STDOUT, so for a simpler interface for debugging warnings...

const warn = @import("std").debug.warn;

pub fn main() void {
    warn("Hello, world!\n");
}

Importing and using C header files is as simple as:

const c = @cImport({
    @cInclude("stdio.h");
});

Master branch documentation https://ziglang.org/documentation/master/

More on why you should care about zig: https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Already-CPP%2C-D%2C-and-Rust%3F

Join us on IRC at irc.freenode.net #zig

Your own dupe:

>>998888 (checked)

>>998896

Shit, didn't realize it did that. :/

>>998897

>>998896

Won't let me delete, pretty sure I'm using the same pw too. Rip

>>998889 (OP)

Wait 1.5 years for JAI

Looks like even more retarded ECMAScript

>muh syntax

I want to like it but every time I look at it I like the syntax less or find another piece of ugliness in it. Like the switch statements.

>>998942

>muh syntax

spotted the LARPer

>>998945

If you think Brainfuck is a bad language then you're a hypocrite.

>>998946

>if you think Brainfuck is a bad language it HAS to be because of its syntax

Protip: Brainfucks syntax is fine. There are other issues with it.

Kill yourself, LARPer.

>>998945

Double LARPer detected. Syntax can be a real issue. Look at Scala or C++.

>>998966

>muh syntax

LARPer spotted

>>>/g/

>>998923

Currently doing this.

>>998923

They don't really have the same goals, for example Jonathan Blowe loves implicit calls while zig purposefully avoids anything not explicit

>>999003

An JAI doesn't look like Perl.

I'm still waiting for a language that is actually safe, that has NO edge cases where it crashes (unlike Rust). I have yet to see a language that handles stack overflows properly without crashing. Zig doesn't have that yet, but in the video that OP linked the language's author says he's working on it.

>>999012

Why wouldn't you want it to crash when you fuck up?

>>999048

I'd my software be able to clean up after itself if it fucks up. Or even better, to recover from the error and continue in a well-defined and consistent state instead of relying on the operating system to simply restart my application.

>>999012

Stop using computers with finite memory. Leave the real world and join the world of academia.

>>999012

with Ada.Text_IO;         use Ada.Text_IO;
with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;

procedure Smash is
   procedure Smashit (N : in Integer) is
   begin
      Put (N, Width => 0);
      New_Line;
      Smashit (N + 1);
   end Smashit;
begin
   Smashit (0);
end Smash;

$ ./smash
...
174474
174475
174476
174477

raised STORAGE_ERROR : stack overflow or erroneous memory access

how's that?

60% of the time that same program dumps core

>>999057

How about doing your job correctly? How about taking some responsibility and having some kind of quality control instead of wasting system resources because your software is shit?

>>999062

Show me your quality control that checks stack usage.

>>999061

Looks like guard pages, which requires paging. You automatically have those in your C programs, too. But that's not what I'm talking about. Crashing with a message is not "recovery".

>>999064

That's an exception, so you can catch it:

174534
174535
shit's fucked, trying to recover...done

with Ada.Text_IO;         use Ada.Text_IO;
with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;

procedure Smash is
   procedure Smashit (N : in Integer) is
   begin
      Put (N, Width => 0);
      New_Line;
      Smashit (N + 1);
   end Smashit;

   Running : Boolean := False;
begin
   Running := True;
   Smashit (0);
   Running := False;
exception
   when Storage_Error =>
      Put ("shit's fucked, trying to recover...");
      Running := False;
      if Running then
         Put_Line ("and we failed!");
      else
         Put_Line ("done");
      end if;
end Smash;

>>999065

How would one write an OS that recovers from kernel stack overflows?

Also how can you be sure that your stack overflow never overwrites any of your application's other data? I think your stack-allocated objects would have to never be larger than your OS' guard page size, whatever size that may be. Imagine you were to put a large (multiple megabytes) object on the stack on a platform where the stack grows downwards. If you start writing to that object, you could potentially start writing below the guard page where other application data might be.

>>999066

statically check stack sizes for kernel code

in case of non-tail recursion, have a hard limit on the number of calls which is proved statically to be impossible to exceed

problem solved

>>999062

you really don't understand manual memory management

>>999005

>>998923

What?

Zig looks nothing like perl, and that's coming from someone who has used perl for years (I don't recommend it). Zig is practically the antithesis of perl

>>999066

Place the stack in a separate segment, like in the good old DOS days. Enjoy the return of near and far pointers.

More realistically, we have 64 bits of address space now. Make the guard page gigabyte large. Problem solved.

>>998889 (OP)

You forgot the most important feature: IT MOVES FOR GREAT JUSTICE

Andrew's youtube channel: https://www.youtube.com/user/superjoe30/videos

>>999012

It does already offer the possibility for smart developers to make crash-less code in ways that C didn't.

>>999012

>>999057

it crashing your shitty code is a good thing. buggy code is a security hole, forcing you to work it out is a good thing. shitty software should crash more, like it does when you try to run it on openbsd

>>999539

that is what happens with zig, just the compiler commonly calls you a retard if it detects shitty code ontop of that

>>999539

>>999542

it's the POSSIBILITY of making bug-free software while retaining its low-level eyesight that zig is aiming to achieve

>hurr replaces C guyz!

Yeah yeah, alright then OP.

https://odin.handmade.network

Fuck Zig

>>999577

Is this meme vaporware edition of Jai

>>999581

Isn't zig exactly the same thing

>>999577

slower activity than a bag of rocks, looks shit

>>999630

no

>>999663

Let's say I wanted to start a project in either Odin or Zig.

Which language should I choose and why ?

So far all I can see is Odin works and has third party libs, while Zig only compiles on x64 and has a ton of issues. But I didn't actually use either.

>>999665

>wanting to start a project in an unstable language maintained by only one developer

I wonder what happens when that one's developers money runs out?

>>999577

>>999664

>Odin dumps core after compilation

>Myrddin doesn't even compile; build system doesn't notice early failures

>>999630

>Jai doesn't exist

yeah it's a real puzzle

why is this thread here about this language that actually works?

>>999080

What happens if it hits the maximum recursion depth?

>>999199

>Place the stack in a separate segment

That's very architecture specific.

>Make the guard page gigabyte large.

Sounds kinda arbitrary.

>>999722

read:

>have a hard limit on the number of calls which is proved statically to be impossible to exceed

what happens is that compilation fails due to the failure to prove, statically, that the program won't exceed the limit.

>>999665

You can use any C/C++ library in zig, and it is more stable than Odin in my experience (despite being so young).

>>998890

Absolute shit syntax, just like C. It's garbage.

>ctrl+f

>no aybabtu posting

The internet is truly fucked.

>>999829

times have changed

>>999012

Choke on this, nigger.

sudo apt-get remove rust* libstd-rust* cargo*

sudo apt-get remove snapd* libsnapd*

>>999829

Look harder.

>>999972

he'd never do that with the amount of soy he's ingesting

>>998889 (OP)

Rust made Zig obsolete before it was even created.

>>1000161

see >>1000156

>>999747

You can't really limit recursion depth statically if it depends on user input. Whether or not it depends on user input is going to be difficult to check. Unless maybe you use a pure language that makes you consider all kinds of side effects, like Haskell, but at least that one has its own downsides.

>>1000254

>You can't really limit recursion depth statically if it depends on user input.

No but you can detect when it is dependent on user input and then require the error to be manually handled.

>>1000254

you can, by passing along a number of recursive calls and end the recursion if that number reaches a limit.

>>998889 (OP)

Why not just use Crystal?

Why is the syntax so ugly tho?

>>1000340

>garbage collected

unusable for the same things

>>1000255

How do I manually handle stack overflows that may or may not hit the guard page? Also if recursion depth did not depend on user input then I could compute its value at compile time.

>>1000273

How do I know that number?

>>1000481

wtf Haha bro epic

>>1000453

>How do I know that number?

def op_dick(*some_shit, recursive_calls=0):
    if recursive_calls > 10:
        return 'deal with it'
    # do some shit
    a = op_dick(*some_shit, recursive_calls=1+recursive_calls)
    b = op_dick(*some_shit, recursive_calls=1+recursive_calls)
    return a + b

A hypothetic compiler can verify that:

1) the recursion ends on a simple condition depending only on arguments

2) the initial value of the argument has a sufficient lower bound (at every call site)

3) with each step the value goes strictly towards the condition which terminates

Of course there will be some cases where it's not obvious for compiler, then you need to either make it obvious or don't use recursion if possible.

>>1000340

not the same at all

>directly compete with C

repost this thread when it gets any microcontroller support or other low level chip support from manufacturers till then there is no chance for it to compete. it will just be a hipster language.

>>1005239

what are you talking about?

there has already been a thing that the main guy made where he booted directly into a written-in-zig kernel

look at all of the architectures zig directly supports

>>1005255

i said manufacture support. how development works in the real world for bare metal programming on micro controllers and the like is that manufactures both try to sell to companies with their chips specs and their development software/kit for the chip. the IDEs the compilers and maybe emulators they give out for free. so lets say your company you work for wants to development some chip, are you going to use ZIG because some guy says it fully supports your chip on the internet? or are you just going to use the C compiler the company that makes the chip gives you which you will get support for and you know is fully compatible. then think about the fact your engineer staff only knows C and the new people to come in also know C and not ZIG. and lets say you arent a larper talking about a hipster tier language and you want to get a job. is it worth learning ZIG? no fuck off nigger larper.

>>1005263

You have no comprehension capabilities.

>>1005263

>how development works in the real world for bare metal programming on micro controllers and the like is that manufactures both try to sell to companies with their chips specs and their development software/kit for the chip.

I hate these shitty IDE's that each tries to sell, and I refuse to work with any microcontroller that does not have a working gcc toolchain ala the MSP's / STM's. Theoretically, for any platform where there's a FOSS compiler, there's no reason zig could not support these systems.