Live data from Hacker News

File for divorce from LLVM

github.com

121–130 of 167 posts

Re: File for divorce from LLVM

#121
post #111

Earlier quoted context omitted.

Having the choice for advanced users is a plus but I think having to choose is a big negative.

Most importantly it results in a significantly increased workload for the maintainers, and spreads out effort over a bigger area. So the most likely outcome is a language with multiple mediocre compilers, instead of one really good one that everyone works on. Which is the exact opposite of what the intention behind this proposal is, which is to make the language more maintainable.

LDC and GDC are both very good compilers.

Technologically D suffers more from having a single frontend implementation than having multiple backends.

Re: File for divorce from LLVM

#122
post #119

Earlier quoted context omitted.

You still need a separate compiler toolchain next to Rust in order to compile the C, C++ and ObjC dependencies which is a massive build system headache (especially across UNIX-oids and Windows). In Zig that all "just works" with the standard Zig install.

Show me a C/C++ project that doesn't need a build system.

My stuff for instance:

https://github.com/floooh/sokol

...inspired by:

https://github.com/nothings/stb

(here's how the sokol headers are integrated into a Zig project, note that there is only a build.zig which builds everything: https://github.com/floooh/kc85.zig)

But it's not so much about build systems, but requiring a separate compiler toolchain to build any C++ or ObjC dependencies (Rust needs this, Zig currently does not - unless that controversial proposal is implemented).

(also even complex C++ libraries can be wrapped in a build.zig, so you don't require a separate build system like cmake for the C++ dependencies)

Re: File for divorce from LLVM

#123
My feeling is that if Zig drops C++ support, there seems to be enough momentum on the C++-dependent users, that they will just fork Zig...

Can't LLVM be optional, and have unit tests guarantee that it works as before?

The above, or - as mentioned elsewhere, implement a C++ compiler in Zig: quickly, and before making any breaking changes - quite a tall order.

Or bring into Zig an existing pure-C, C++ compiler.

...TinyC/libtcc? PCC? LCC? (wild guesses)

Re: File for divorce from LLVM

#124
post #108

Earlier quoted context omitted.

Counter-example: Kotlin.

Not at all, given the way Google is pushing it on Android, they are even mischievous enough to compare Kotlin with Java 6 when going on about why Kotlin. For all practical purposes ART has turned into the Kotlin Virtual Machine. However it so happens, that to keep the advantage of using Java libraries in the Android ecosystem, they actually need to support newer Java libraries unless they feel like rewriting all of t…

The idea Kotlin wouldn't be successful without Android isn't right. It was taking off in a big way even before Android did anything with it officially. Google's stated rationale for adopting it was because developers were already migrating to it regardless of what Google wanted.

Re: File for divorce from LLVM

#125

Earlier quoted context omitted.

Counter-example: Kotlin.

How is that a counter example? Doesn’t Kotlin fulfil a similar role for Android?

Kotlin wasn't created by Google and wasn't pushed by them. It's more like they accepted it because the Android developer base was adopting it organically en-masse anyway. That's also the case for many other places where Java is used.

Re: File for divorce from LLVM

#126
post #108

Earlier quoted context omitted.

Not at all, given the way Google is pushing it on Android, they are even mischievous enough to compare Kotlin with Java 6 when going on about why Kotlin. For all practical purposes ART has turned into the Kotlin Virtual Machine. However it so happens, that to keep the advantage of using Java libraries in the Android ecosystem, they actually need to support newer Java libraries unless they feel like rewriting all of t…

The idea Kotlin wouldn't be successful without Android isn't right. It was taking off in a big way even before Android did anything with it officially. Google's stated rationale for adopting it was because developers were already migrating to it regardless of what Google wanted.

Google is in bed with JetBrains in what concerns Android.

Re: File for divorce from LLVM

#127

Earlier quoted context omitted.

How is that a counter example? Doesn’t Kotlin fulfil a similar role for Android?

Kotlin wasn't created by Google and wasn't pushed by them. It's more like they accepted it because the Android developer base was adopting it organically en-masse anyway. That's also the case for many other places where Java is used.

It was pushed by Android team, the same folks that came up with Jetpack stuff.

Additionally JetBrains has their fingers all over the place in Android.

Kotlin, Android Studio a mix of InteliJ and Clion, Compose,...

Re: File for divorce from LLVM

#128

My feeling is that if Zig drops C++ support, there seems to be enough momentum on the C++-dependent users, that they will just fork Zig... Can't LLVM be optional, and have unit tests guarantee that it works as before? The above, or - as mentioned elsewhere, implement a C++ compiler in Zig: quickly, and before making any breaking changes - quite a tall order. Or bring into Zig an existing pure-C, C++ compiler. ...Tiny…

...or include an external C++ to C transpiler?

Re: File for divorce from LLVM

#129
post #119

Earlier quoted context omitted.

Show me a C/C++ project that doesn't need a build system.

My stuff for instance: https://github.com/floooh/sokol ...inspired by: https://github.com/nothings/stb (here's how the sokol headers are integrated into a Zig project, note that there is only a build.zig which builds everything: https://github.com/floooh/kc85.zig ) But it's not so much about build systems, but requiring a separate compiler toolchain to build any C++ or ObjC dependencies (Rust needs this, Zig currentl…

I still don't see why this is a problem. Single-header dependencies are cute but blow up compile times, and most of the world needs CMake/Meson/Autotools anyways so there's not an added cost to using it for your own projects.

Similarly I don't really understand why you want one toolchain for a multi-language project. It's not that useful or convenient since it's going to need to be orchestrated with a buildsystem somehow.

Like with Rust, you probably only have a build.rs file. It invokes a separate (possibly multiple) toolchains. Or with CMake. A simple project has a single CMakeLists.txt that can invoke any number of toolchains. I don't see why zig can't do that with a build.zig file, or why it matters.

Re: File for divorce from LLVM

#130
post #15

This move... is it for great justice?

I see your comment is getting downvotes, but that's probably because people didn't get the joke. In addition to being the name of the programming language, Zig is a character in the old Namco 'Zero Wing' game, which is where the meme "All your base are belong to us" comes from [1]. "For great justice" is part of the same meme. [1] https://en.wikipedia.org/wiki/All_your_base_are_belong_to_us

> but that's probably because people didn't get the joke.

It’s more that Hacker News tends to collectively frown upon posts that are only jokes, if I had to guess.

Post reply on HN