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

241–250 of 285 posts

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

#241

Post by arc776 »

fyzix wrote: post #167
cercatrova wrote: post #32

I was thinking of learning Rust but it seems a bit overkill due to manual memory management as compared to languages with similar speed like Nim, Zig, and Crystal. How would one compare these languages? Is it worth learning Rust or Zig and dealing with the borrow checker or manual memory management in general, or are GC languages like Nim or Crystal good enough? I'm not doing any embedded programming by the way, just…

Nim strikes a great balance. No need for a low level language for cli and general software. I liked crystal but the lack of support on windows and lackluster dev experience made me stick to Nim. Nim also can double as a web language by transpiling to JS.

Nim's super power is being ridiculously productive (at least for me). Hack stuff out like a Python script, yet it runs really fast and is a tiny self contained executable, so you can just use it as is and move on to the next task. If you want manual memory management, that's easy too. Want to use a C/C++ library? No worries you have ABI compatibility. As you mention compiling to JS lets you use it as a web language and share code and types between front and back end.

Then you can automate code generation with the sublime macros, which are just standard Nim code to create Nim code. No new syntax or special rules required - any Nim code can be run at compile time or run time, so you can use standard/3rd party libraries at compile time to write macros and give the user a slick syntax whilst removing boilerplate.

I really miss languages without straight forward metaprogramming after using Nim. It's something that multiplies the power of a language, rather than just adds to it.

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

#242

Post by bscphil »

zozbot234 wrote: post #233
bscphil wrote: post #222

Earlier quoted context omitted.

Suppose I wanted to try learning Rust again; is there a resource for someone with a lot of (hobbyist) programming experience, and experience with low level languages and memory management (e.g. C), but not complicated low-level languages, like C++? When I tried to work with Rust a few years ago I found it utterly impenetrable. I just had no idea what the borrow checker was doing, did not understand what the error mes…

> Suppose I wanted to try learning Rust again; is there a resource for someone with a lot of (hobbyist) programming experience, and experience with low level languages and memory management (e.g. C), but not complicated low-level languages, like C++? The official Rust book is targeted at novices with some programming experience. There's also Rustlings https://github.com/rust-lang/rustlings for a more practical approa…

Fair enough, I do need to have a look at the book again, although that was one of the sources I found impossible to understand a few years back. I think there's a temptation to talk about lifetimes in extremely abstract terms under the assumption that the reader already understands and appreciates the abstraction. I, however, was never able to build up an intuition for it, and so tutorials that didn't explain what was happening in detail sailed over my head.

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

#243

Post by mkl »

skrebbel wrote: post #87
fouronnes3 wrote: post #5

Are there any languages out there that can only be compiled by a compiler written in their own language? Presumably because the original pre-dogfood compiler stopped being maintained years ago. So that if we somehow lost all binaries of the current compiler, that language would effectively be lost?

TypeScript

Nope: https://github.com/swc-project/swc

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

#244

Post by coder543 »

varajelle wrote: post #210
______-_-______ wrote: post #201

Earlier quoted context omitted.

100%. I would actually go further and say every value should be dropped immediately after its last use, including temporaries in the middle of statements, whether or not it implements Drop. Reuse the same rules that NLL uses. Breaking change yes, so do it next edition. It would lower memory usage in general and solve so many little pain points, not least of which is holding strings across await points.

fn foo(xx : &Mutex ) { let lock = xx.lock(); let ptr = &mut *lock as *mut String; unsafe { use_from_c(ptr) } } You get the idea: you don't want the lock or the string to be dropped before the unsafe code, even if the actual string is no longer used. That's the breaking change. It's hard to detect automatically, so hard to justify even in an edition.

I generally agree with you (which is why I made an exception for values with a manual Drop implementation), but to advocate on behalf of the idea… I don’t think it would be too crazy to make a rule that any function that invokes “unsafe” (or is itself defined as an unsafe function) would fall back to the old scope-based drop rules. Worst case scenario is that you’d be dealing with the current level of memory usage efficiency, and you might need to manually call drop if you want something dropped earlier, but in most cases things would be eagerly dropped even sooner.

Outside of uses of unsafe, are there any other serious problems with eagerly dropping values that manually implement Drop? Maybe this fallback mechanism would also have to be invoked simply for casting to a raw pointer anywhere in the function. Either way, a list of exceptions to eager drop would arguably be better than not having eager drop, as long as the list was sound.

It would still be a breaking change, and would definitely require at least being restricted to a new edition. Some people currently use Drop as a kind of scoped “defer”, especially for things like instrumentation, so maybe it would be time for the language to introduce a proper “defer” statement that exists for that purpose instead of making Drop so lazy for everyone.

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

#246

Post by Tozen »

cercatrova wrote: post #174
Tozen wrote: post #171

Earlier quoted context omitted.

Besides Rust and Zig, you might want to check out Vlang and Odin, who are in the same category.

I remember reading a lot of controversy about V back when I first heard about it so I decided not to look into it further [0], but I'll take a look again. Odin looks interesting, Pony does as well. [0] https://news.ycombinator.com/item?id=25511556

A lot of the so-called Vlang controversy appears to have been disguised allegiance and competition between the newer languages. Looks more like various people defending their interests. Languages like Odin, Zig, Nim, Crystal are far older than Vlang. When Vlang came along and got a lot of sudden popularity and funding, looks like various competitors sought to bash it and hoped it would disappear.

In addition, such detractors were acting like a brand new programming language would be a finished polished product from day 1, when that was not the case for their far older languages. For instance, Odin and Crystal are older than Vlang, but has been surpassed by it in various respects.

And don't get me wrong, I like Odin. That's because Odin is among the newer breed of languages that have continued the trend in which Go started of non class-based OOP and more generalized OO, that are contenders to be alternatives to C/C++ (like Zig).

In the case of Vlang, it has clearly been developing rapidly and consistently, and continually gaining in popularity. Simply looking at their releases (and release schedule) along with their documentation (which various newer contenders are lacking in even that), will show a lot of the controversy is without merit or distortions of language development reality.

https://github.com/vlang/v/releases https://github.com/vlang/v/blob/master/doc/docs.md https://modules.vlang.io/

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

#247

Post by blippage »

elcritch wrote: post #179
geodel wrote: post #146

Earlier quoted context omitted.

Would you tell about those languages or they are left as an exercise to readers?

Sort of left it to the readers and hopefully encourage people to investigate for themselves. It's far too easy to get into "this benchmark vs this benchmark", etc. Memory usage is overall a complicated topic, which I think Andrew's comment doesn't do justice to. Granted the Zig team has done some impressive work, much of the memory usage & bloat in the C++ world comes from real world programs and libraries and the in…

Odin doesn't work on 32-bit ARM, which was a disappointment to me.

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

#248

Post by kaba0 »

varajelle wrote: post #115
coder543 wrote: post #50

Earlier quoted context omitted.

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

You can just put a single pair of bracket around it and that’s it.

For locks it is seriously the best way to manage them.

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

#249

Post by kaba0 »

tialaramex wrote: post #230
charcircuit wrote: post #206

Earlier quoted context omitted.

Can you explain the difference between these approaches? Is it just that the first example allocates an extra u16 (tag of the tagged union) (ignoring any overhead)?

Notice that if I make this alleged "List" with a single data item in it, my data lives in the List object I just made (probably on the stack), but an empty List gets allocated on the heap. I thought Aria's "Entirely Too Many Lists" tutorial actually tries to build this, but it actually doesn't, she draws you the resulting "list" and then is like, OK, that's clearly not what we want, let's build an actual (bad, slow,…

I don’t really get your example, or how does it have to do anything with rust? It’s just a bad linked list, isn’t it?

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

#250

Post by kaba0 »

exikyut wrote: post #134
pjmlp wrote: post #16

Earlier quoted context omitted.

Kotlin has seen fantastic adoption in Android projects, because of the way Google pushes it, while stagnating Android Java on purpose. On the JVM world not really. https://www.infoq.com/news/2022/03/jrebel-report-2022/

Huh. I read about this the other day as well - https://news.ycombinator.com/item?id=30842602 : > If only [Oracle] hadn't sued Google, Java would still have been the pre-eminent language for Android development. Sadly Android is stuck at legacy Java 8 permanently now. So, modern Java is stuck as a server-side language with dozens of competitors. A reply argued that Android is on Java 11 now, and then you noted (hi!) t…

The whole Oracle google lawsuit had nothing to do with modern Android’s use of Java — java has been open-sourced since and for a long time now (by oracle themselves).

The lawsuit was about Sun’s license that explicitly demanded a purchase for use on mobile devices for their Java programming language (as that was the area they wanted to get money from). Google instead copied most of the APIs and called it a day, and Oracle bought Sun and went after the lawsuit.

But since the license changed in the meantime so that OpenJDK is completely open-source and has the same license as the Linux kernel, it was all about an older state of things.

Post reply on HN