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

File for divorce from LLVM

github.com

Post reply on HN
Print view View original

91–100 of 167 posts

Re: File for divorce from LLVM

#91

Post by pjmlp »

flohofwoe wrote: post #87
Hermitian909 wrote: post #59

Earlier quoted context omitted.

I'm reminded of a recent interview with Chris Latner about the success of Swift - he credits the success to the fact that you could start with a large objective C project and begin writing Swift without rewriting anything. Part of Rust's success is off the back of a similar compatibility with C/C++. It is difficult for me to imagine Zig succeeding without a similar capability - which is to say I hope they do not foll…

Can Swift really be called a success when it's only being used in the very narrow niche (the Apple software ecosystem - and only because it's essentially dicated by the platform owner)?

Yes, that is how languages become a success on the market, either being pushed by the platform owner no matter what, or by having a framework written in them that everyone feels like using.

Everything else are aspiring extras in the cinema of programing languages, waiting on the sidelines for that major role that will come someday, it really will, one just has to believe enough.

Re: File for divorce from LLVM

#92

Post by pjmlp »

Solvency wrote: post #52
defen wrote: post #48

Earlier quoted context omitted.

I agree that it's probably impossible to write something that is orders of magnitude faster than LLVM and better than LLVM at optimizing, but I don't see that claim in the original text. It seems like a lot of work but also doable to create something that is orders of magnitude faster than LLVM for unoptimized debug builds. Furthermore, the Zig compiler might be an easier thing to work with than LLVM/Clang for doing…

Just to play devils advocate..who would've thought Javascript would ever end up as blazingly fast as it has become since V8. Maybe Zigworld can do it.

Anyone that has ever played with dynamic languages like Smalltalk and SELF, or read their research papers.

Re: File for divorce from LLVM

#93

Post by mike_hearn »

pjmlp wrote: post #91
flohofwoe wrote: post #87

Earlier quoted context omitted.

Can Swift really be called a success when it's only being used in the very narrow niche (the Apple software ecosystem - and only because it's essentially dicated by the platform owner)?

Yes, that is how languages become a success on the market, either being pushed by the platform owner no matter what, or by having a framework written in them that everyone feels like using. Everything else are aspiring extras in the cinema of programing languages, waiting on the sidelines for that major role that will come someday, it really will, one just has to believe enough.

Counter-example: Kotlin.

Re: File for divorce from LLVM

#94

Post by frmdstryr »

audunw wrote: post #42
frmdstryr wrote: post #16

So I spent ~4 years writing all my embedded projects (and libraries) in Zig and now several "tier 1" supported arches are just going to be dropped? It's your language so do whatever you want but please adjust the branding accordingly...

Are they being dropped? Im guessing you'll have two categories of tier 1 support: - Built-in tier 1 support. - Tier 1 support through the optional LLVM backend. If they already have tier 1 support for an architecture, I don't see why they'd loose that support when they make the LLVM backend an optional dependency? And as Andrew writes in the proposal, this way might provide a path for better support for more obscure…

"In the near term it would also reduce the number of targets Zig supports", I hope not but it sure sounds like it.

Re: File for divorce from LLVM

#95

Post by fulafel »

sanxiyn wrote: post #77
plorkyeran wrote: post #27

Earlier quoted context omitted.

It's not obvious that "LLVM, but not incredibly frustrating" is a thing which can exist. I don't think it's likely, but it's possible that in a few decades the widespread view will be that the very concept of LLVM was a mistake, and a universal compiler backend is just a trap which makes it easy to bootstrap a language but inevitably causes massive problems down the road. LLVM does have plenty of incidental problems…

MLIR is "LLVM done better", in fact by the same person. It fixes many of unforced LLVM problems, for example LLVM's inability to parallelize code generation.

MLIR is part of LLVM, no? And going by the website sounds like it uses LLVM (or bring-your-own) backend for platform specific code generation.

Re: File for divorce from LLVM

#96

Post by Dennip »

Does anyone have any good examples of Zig being used as a build system for a large project?

Coming from a Windows world when my gigantic C++ project is hidden inside a vcxproj I dont delve into that often, I tried to compile a standard autoconf based project into wasm the other week and eventually gave up.

Use autoconf to create your cmake to create your make which builds your lib? and wrap all those calls with emscripten calls...or something along those lines. It was exhausting. Eventually it errored out becuase it couldn't decide if the size of a size_t was available. I was tempted to just remove that line from the cmake.

Re: File for divorce from LLVM

#98

Post by jimwhite42 »

wyldfire wrote: post #56

Andrew is super sharp so I imagine he and the team will get there now that it's declared as a goal. But man, it seems to me (uneducated on the challenges zig faces w/LLVM) that this shifts the team's capacity away from zig and towards things like binutils. When I read the headline I assumed that they were throwing out the compiler (IIRC they had mostly/totally excised it already). But for a project like zig it just s…

There's a document that I think was an unofficial project management document from NASA, I can't find it now, but one of the items was something along the lines of 'if your space mission isn't reusing an existing launch vehicle, it will be a launch vehicle development project and everything else, including what you think is the focus of your mission, will be secondary to this'.

Edit: additional bit I remembered, this statement is prefixed with something like 'you may start thinking you project will be cheaper/more efficient if you develop a launch vehicle suited to your particular mission instead of compromising on an existing one, but', then the above.

Re: File for divorce from LLVM

#100

Post by the_duke »

higherhalf wrote: post #86
Ashymad wrote: post #64

Earlier quoted context omitted.

But rust absolutely does not have any C/C++ compatibilty besides arguably very good FFI. And that's where zig shines. They have a c/c++ compiler built into the zig compiler via zig cc, that's even easier to use than clang or GCC due to having the benefits of a buildscript and baked in libcs for different architectures, making crosscompilation a breeze. In zig you _can_ actually start with a c codebase and rewrite it…

> But rust absolutely does not have any C/C++ compatibilty besides [..] > In zig you _can_ actually start with a c codebase and rewrite it file by file in zig and you _can_ include c headers in your zig files verbatim. Both of these are not possible in rust. You can. Either via FFI and bindgen-ing headers, or by using c2rust. The latter is not just a toy ambitious project, but actually a very impressive piece of engi…

c2rust is definitely cool, but it also supports transpiling to a single architecture, which often misses a lot of architecture dependent code and specialisations in real world c code. Especially because it has to do macro expansion and you only get the expanded code.

It also doesn't supportal a good amount of more complicated c features.

It's a help for sure, but the few times I tried I ended up just doing the rewrite by hand instead to actually cover all the cases.

Post reply on HN