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

Zig self hosted compiler is now capable of building itself

github.com

Post reply on HN
Print view View original

111–120 of 285 posts

Re: Zig self hosted compiler is now capable of building itself

#111

Post by RustyConsul »

charcircuit wrote: post #52
lupire wrote: post #29

Earlier quoted context omitted.

I think Zig prefers explicit memory management, because allocations may fail and should be handled explicitly, and because automatic deallocations lead to hard-to-predict lifetimes (excess memory usage, and bugs for resource handles that are destructed at hard to predict moments). These are things that a "systems language" programmer should put in the work to do correctly/near-optimally, and not ask the compiler to j…

The lifetime of the memory a smart pointer manages is very predictable. It will have the same lifetime as the smart pointer itself (this is ignoring moves).

I think what he's saying is there is a way to carelessly use smart pointers in rust.

pub enum List { Empty, Elem(i32, Box), }

instead of :

pub struct List { head: Link, }

enum Link { Empty, Some(Box), }

struct Node { elem: i32, next: Link, }

Re: Zig self hosted compiler is now capable of building itself

#112

Post by elcritch »

cercatrova wrote: post #43
sanxiyn wrote: post #39

Earlier quoted context omitted.

Zig uses manual memory management too (even more manual than Rust), so that's a bit strange question.

Interesting, based on their code samples it looked to me like a GC language since (at least from what I saw) I didn't see anything regarding memory management.

It’s easy, IMHO, to mistake Zig as a GC’ed language or more broadly as a memory safe systems language. It’s neither but it is a nicer C.

Re: Zig self hosted compiler is now capable of building itself

#113

Post by pjmlp »

messe wrote: post #109
pjmlp wrote: post #95

Earlier quoted context omitted.

And as we know from C, every developer is quite capable of taking care of use after free possible bugs.

The general purpose allocator in the zig standard library has protections against use after free bugs.

Just like C and C++ debugging allocators, so what is the improvement here?

Re: Zig self hosted compiler is now capable of building itself

#114

Post by mlinksva »

kristoff_it wrote: post #15
jonpalmisc wrote: post #6

I think Zig’s compatibility with C is such a valuable feature. I also wish we could rewrite everything in a modern language, but the reality is that we can’t and that if we could, it would take a LONG time. The ability to start new projects, or extend existing ones, with a modern and more ergonomic language—Zig—and be able to seamlessly work with C is incredible. I look forward to the self-hosted compiler being compl…

> I also wish we could rewrite everything in a modern language, but the reality is that we can’t and that if we could, it would take a LONG time. The ability to start new projects, or extend existing ones, with a modern and more ergonomic language—Zig—and be able to seamlessly work with C is incredible. That's the Maintain it With Zig approach :^) https://kristoff.it/blog/maintain-it-with-zig/

Sounds compelling. Is there a list of projects following this advice anywhere?

Re: Zig self hosted compiler is now capable of building itself

#115

Post by varajelle »

coder543 wrote: post #50
lupire wrote: post #29

Earlier quoted context omitted.

I think Zig prefers explicit memory management, because allocations may fail and should be handled explicitly, and because automatic deallocations lead to hard-to-predict lifetimes (excess memory usage, and bugs for resource handles that are destructed at hard to predict moments). These are things that a "systems language" programmer should put in the work to do correctly/near-optimally, and not ask the compiler to j…

> because automatic deallocations lead to hard-to-predict lifetimes (excess memory usage, and bugs for resource handles that are destructed at hard to predict moments). I don't really feel this is the case in Rust.

But it is. If you have a String on the stack, it's memory is only reclaimed at the end of the scope, while it often could be free'd before. This is especially bad in async code around await point since it means the memory need to be kept alive more than needed.

Re: Zig self hosted compiler is now capable of building itself

#116

Post by ByteJockey »

mhh__ wrote: post #72
ByteJockey wrote: post #65

Earlier quoted context omitted.

Don't most toolchains have a rather large C++ component? Just parsing C++ is a rather large undertaking (my understanding is that it's syntax is turing complete).

So you start with a C++ compiler written in C. Hence bootstrap, rather than compile from source.

Oh, gotcha. Sorry, brain wasn't parsing right before the coffee today.

Re: Zig self hosted compiler is now capable of building itself

#117

Post by npn »

pizza234 wrote: post #92
jgillich wrote: post #64

Earlier quoted context omitted.

I've found that Go is not elegant enough for me and Rust is too difficult to write (I started using Rust in 2015 and after years of trying I eventually realized Rust doesn't make sense for most apps), so I'm all in on Crystal. Despite not having much prior Ruby experience, I absolutely love the language.

Crystal doesn't have built-in support for parallelism, let alone production-grade support. This is a significant lack for a modern language. For a language that is around 8 years old, this may be a serious problem, since the surrounding ecosystem has been probably written without parallelism in mind, and it may take a very long time to be updated (if ever).

> Crystal doesn't have built-in support for parallelism

They do, but it is hidden inside a compiler flag, if you compile your prject with `Dpreview_mt` then it will come with multi-threaded support. This has been an experimental feature for a few year though, and there is not much improvement since it first got introduced.

Personally I don't use crystal for this kind of feature, and it runs stable enough when I use it for some cpu intensive tasks when I rarely need it.

Crystal really shines when you need something that you usually write a python/ruby script to do, especially for tasks that run for hours. Converting some script from ruby to crystal and run it in production mode typically reduce the time consumed to 1/5 or even 1/10 of the original depends on the job. As someone who have to read gigabytes of text files regularly, Crystal is currently the best one for the task.

The compilation time for released binary is something need much improvement though. And I'm not sure if they can even achieve incremental compilation.

Re: Zig self hosted compiler is now capable of building itself

#118

Post by ledgerdev »

pacaro wrote: post #90
ledgerdev wrote: post #85

I have been thinking about creating a little higher level language that targets server side web assembly. Zig looks very attractive, but concerned with how to handle things like strings and datetimes. How suitable is zig for such a task compared to say rust?

I may be misunderstanding you, but it feels like strings and datetimes are library related more than language related. I know that higher level languages will have primitives that aim to represent strings, but if you need to get into the weeds with Unicode then you'll be leaning on a library regardless

> I may be misunderstanding you, but it feels like strings and datetimes are library related more than language related.

Yes would agree and see them as platform related. It's just too large a task to create from scratch. Like say on JVM you can compile to bytecode and have strings already built into platform, and java.time, and ability to access an ecosystem of libraries.

With zig could one could use c or rust libraries?

Re: Zig self hosted compiler is now capable of building itself

#119

Post by elcritch »

pjmlp wrote: post #96
Comevius wrote: post #59

Earlier quoted context omitted.

When tail latency (high-percentile latency) is important GC is not a good choice. Wait-free (threads progress independently) concurrent algorithms also need wait-free memory reclamation with bounded memory usage to be able to guarantee progress. But most software are throughput-oriented.

Additionally, not all GCs are made alike, and languages like D, F#, C#, Nim, Swift, among others, also offer value types and manual memory management, if desired.

Also Swift and Nim w/ ARC use reference counting, which generally give much better latency and lower memory overhead. Reference counting is part of the reason iOS devices don’t need as much RAM.

Nim’s ARC system also doesn’t use atomic or locks which means it’s runtime overhead is very low. I use it successfully on embedded devices for microsecond timed events with no large tail latencies.

Re: Zig self hosted compiler is now capable of building itself

#120

Post by sedatk »

pjmlp wrote: post #26
holoduke wrote: post #24

Earlier quoted context omitted.

Are they pushing? Most documentation for Android dev is still Java. Or by default Java. It's only the Intelij guys pushing for Kotlin by creating a lockin in their IDE. One reason I refuse to use it.

You have missed all the Kotlin only Jetpack libraries, NDK documentation now using Kotlin, Jetpack libraries originally released in Java now rewritten in Kotlin. They are still using Android Java on the system layers, because they aren't rewriting the whole stack. Even the update for Java 11 LTS subset on Android 13 is mostly likely caused by the Java ecosystem moving forward, than the willingness of Android team to…

> You have missed all the Kotlin only Jetpack libraries, NDK documentation now using Kotlin, Jetpack libraries originally released in Java now rewritten in Kotlin.

Also, Oracle's lawsuit against Google for copying Java APIs.

Post reply on HN