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

Zig 0.4.0 Released

ziglang.org

Post reply on HN
Print view View original

61–70 of 141 posts

Re: Zig 0.4.0 Released

#61

Post by pjmlp »

strmpnk wrote: post #24
earenndil wrote: post #20

Earlier quoted context omitted.

Honestly, I don't see it happening. Zig and rust and jai and d all feast on c's remains, but the result can only be fragmentation. And then you lose one of the big draws of c: ubiquity. Zig has two compilers. Rust has one (serious) compiler. Jai has 1, d has either 1.5 or 3.5 (depending on how you count). And although all those languages want to replace c as the language-that-you-use-for-everything, and they might ea…

I don't see any single thing replacing C (or C++) but what's interesting here is many of these languages work very well with the C ABI, not just as an FFI concept but with notions of memory and data layout. The interesting side effect might be that we'll see Zig not just work with C code but Zig work with Jai with D with Rust. All of that code can still interface with C or C++ code (in both directions). This lowers t…

On Windows we just use COM/UWP or .NET libraries most of the time, no need to be stuck with C ABI.

Same applies on Android, where using a Java based library, even if stuck on their Java 6 - 8 world is much more desireable than having to deal with NDK and JNI boilerplate.

Likewise IBM and Unisys mainframes make use of their language environments instead of C based ABIs.

Re: Zig 0.4.0 Released

#62

Post by pjmlp »

jplayer01 wrote: post #49
earenndil wrote: post #42

Earlier quoted context omitted.

> The interesting side effect might be that we'll see Zig not just work with C code but Zig work with Jai with D with Rust. All of that code can still interface with C or C++ code (in both directions) That already works, not a hypothetical. I can write, right now, a zig function, call it from rust, slap the whole thing into a library and wrap it with d. It hasn't taken the world by storm because these languages provi…

Wouldn't a managed runtime mean it isn't suited for systems programming? The benefit of something like Rust is it provides a lot of the benefits of a managed language while producing native code and "zero-cost abstractions". A runtime adds a lot of overhead etc.

C also has a runtime, that is what takes care of calling main(), handling VLAs, floating point emulation, constructor/destructors (GCC C extensions), ...

Besides there are plenty of OSes written in type safe system languages to learn from, including surviving mainframe OSes.

Re: Zig 0.4.0 Released

#63

Post by p0nce »

flohofwoe wrote: post #60
otabdeveloper1 wrote: post #54

Earlier quoted context omitted.

> All these languages are potentially-better systems languages than C/C++ No they are not. C++ has spent decades building "a better C/C++". Any language that ignores those lessons and takes the stance of "learning C++ is too hard, let's go shopping" is doomed to fail.

Apologies for being a bit blunt, but: For all the time and work poured into C++, it has remarkably little to show over plain old C99. Some of those new "better C" languages are the work of individuals and very small teams, yet they are able to build more progressive "better C" languages than C++ can ever be because it is held back by the need for backward compatibility for 'failed features' and 'design-by-committee'.…

Here are some things that make C++ better than C

- RAII

- exceptions

- classes and objects

- inheritance

- templates

- the STL

C++ is strictly better than C when wielded correctly.

Re: Zig 0.4.0 Released

#64

Post by pjmlp »

abainbridge wrote: post #57
ken wrote: post #36

"Zig is aggressively pursuing its goal of overthrowing C as the de facto language for system programming." If there's one truth I've learned in my decades of dealing with computers, it's that you can't beat C at being C. Before now, I'd never heard of Zig in particular, but I can think of several other languages that have tried or are currently trying. A lot of people seem to think they can make something a little be…

Have you got an example of a C replacement that was actually better than C, got as far as Zig and is now abandoned? I can't think of one. I've been look for a better C for 15 years and Zig is the best candidate I've found. I don't think DasbetterC counts, since it is a side effort to the greater goals of D.

Turbo Pascal, Object Pascal and Modula-2 would be such examples.

Their sin was not being bundled with an OS, originally distributed with source code by a symbolic price.

Re: Zig 0.4.0 Released

#65

Post by flohofwoe »

p0nce wrote: post #63
flohofwoe wrote: post #60

Earlier quoted context omitted.

Apologies for being a bit blunt, but: For all the time and work poured into C++, it has remarkably little to show over plain old C99. Some of those new "better C" languages are the work of individuals and very small teams, yet they are able to build more progressive "better C" languages than C++ can ever be because it is held back by the need for backward compatibility for 'failed features' and 'design-by-committee'.…

Here are some things that make C++ better than C - RAII - exceptions - classes and objects - inheritance - templates - the STL C++ is strictly better than C when wielded correctly.

All of those are very subjective.

- RAII: Only useful with 'smart' data which must run code for initialization, destruction or copying. It's entirely valid to work with 'dumb' data only which is zero-initialized, and can be copied and deleted without any additional custom actions.

- Exceptions: too brittle and complex, modern languages have switched mostly to option-return values, which contain both an error code and success-result.

- Classes, objects, inheritance: left-over artefacts from the OOP hype of the 90's

- Templates: Not the only option to write generic code, other languages do this better. Programming entirely without generics isn't too bad either, not all code benefits from this.

- STL: not sure what to say here, it's the main contributor to slow compile times, excessive hidden memory allocation, slow debug performance and bloated executables. There are not many parts of the STL that are 'acceptable', but of course that's entirely subjective.

Re: Zig 0.4.0 Released

#66

Post by jstimpfle »

pjmlp wrote: post #62
jplayer01 wrote: post #49

Earlier quoted context omitted.

Wouldn't a managed runtime mean it isn't suited for systems programming? The benefit of something like Rust is it provides a lot of the benefits of a managed language while producing native code and "zero-cost abstractions". A runtime adds a lot of overhead etc.

C also has a runtime, that is what takes care of calling main() , handling VLAs, floating point emulation, constructor/destructors (GCC C extensions), ... Besides there are plenty of OSes written in type safe system languages to learn from, including surviving mainframe OSes.

I feel much of the negativity that you like to express towards C is unwarranted. Fact is, it's both very easy and efficient to interface with "C" or more specifically, platforms' standard ABIs.

Re: Zig 0.4.0 Released

#67

Post by mysterydip »

earenndil wrote: post #20
jph wrote: post #3

Zig's new release has a ton of improvements: new targets (e.g. LLVM 8, WASM, support tiers), C pointers, Vector type, better docs, and my personal favorite: Zig now makes things as static as possible by default. I love seeing all the progress with Zig, V, Muon, and Rust. All these languages are potentially-better systems languages than C/C++, with better safety, better definitions, and better semantics. Zig has an ex…

Honestly, I don't see it happening. Zig and rust and jai and d all feast on c's remains, but the result can only be fragmentation. And then you lose one of the big draws of c: ubiquity. Zig has two compilers. Rust has one (serious) compiler. Jai has 1, d has either 1.5 or 3.5 (depending on how you count). And although all those languages want to replace c as the language-that-you-use-for-everything, and they might ea…

Naïve thought of the day: What if instead of replacing c with another c-like language, there was a c library that you included in your code that overloaded operators and functions into safer ones? You would gain some of the benefits and retain the ubiquity.

Re: Zig 0.4.0 Released

#68

Post by Crinus »

pjmlp wrote: post #61
strmpnk wrote: post #24

Earlier quoted context omitted.

I don't see any single thing replacing C (or C++) but what's interesting here is many of these languages work very well with the C ABI, not just as an FFI concept but with notions of memory and data layout. The interesting side effect might be that we'll see Zig not just work with C code but Zig work with Jai with D with Rust. All of that code can still interface with C or C++ code (in both directions). This lowers t…

On Windows we just use COM/UWP or .NET libraries most of the time, no need to be stuck with C ABI. Same applies on Android, where using a Java based library, even if stuck on their Java 6 - 8 world is much more desireable than having to deal with NDK and JNI boilerplate. Likewise IBM and Unisys mainframes make use of their language environments instead of C based ABIs.

> COM/UWP

Assuming with COM/UWP you mean "UWP's flavor of COM" instead of "COM and/or UWP", is anyone actually using that outside of mobile trash and game engine backends for XB1?

All the Windows software i use and see people make are either Win32 or (much more often) built on top of Win32 (well, UWP is technically also built on top of Win32, but you are supposed to ignore that and act as if it isn't the case).

Re: Zig 0.4.0 Released

#69

Post by carlmr »

rat87 wrote: post #34
earenndil wrote: post #20

Earlier quoted context omitted.

Honestly, I don't see it happening. Zig and rust and jai and d all feast on c's remains, but the result can only be fragmentation. And then you lose one of the big draws of c: ubiquity. Zig has two compilers. Rust has one (serious) compiler. Jai has 1, d has either 1.5 or 3.5 (depending on how you count). And although all those languages want to replace c as the language-that-you-use-for-everything, and they might ea…

Maybe I'm a bit of a rust fanboy and a bit of a skeptic but Zig and Jai aren't going anywhere. Zig appears to be a largely single contibutor ( https://github.com/ziglang/zig/graphs/contributors the creator has As for rust we don't know yet how big of a chunk of marketshare it will take from new c and c++ code. Not many people still use c code for "everything", most have already switched.

Rust is especially attractive because of no-GC. Systems, embedded, performance oriented projects have real reasons to adopt this language.

Re: Zig 0.4.0 Released

#70

Post by p0nce »

flohofwoe wrote: post #65
p0nce wrote: post #63

Earlier quoted context omitted.

Here are some things that make C++ better than C - RAII - exceptions - classes and objects - inheritance - templates - the STL C++ is strictly better than C when wielded correctly.

All of those are very subjective. - RAII: Only useful with 'smart' data which must run code for initialization, destruction or copying. It's entirely valid to work with 'dumb' data only which is zero-initialized, and can be copied and deleted without any additional custom actions. - Exceptions: too brittle and complex, modern languages have switched mostly to option-return values, which contain both an error code and…

Well you learn to appreciate the value of RAII and exception working on high-availability software. It's almost impossible to have correct error paths and deinitialization without. I'm very doubtful the new crop of languages without exceptions and RAII actually care about correctness in the wild.

Better than template without uniform representation? template is just copy-paste you don't _have_ to use it. Same remark for STL. You want a hashmap of arrays of string, you can have it in C++ in one line. In C you would end up with a linked list instead of picking the right data structure.

Objects and inheritance are not a hype. See this page, which uses CSS, which implements inheritance. Having subtyping is a basic premise of being a useful language (or, a GUI language).

Post reply on HN