Live data from Hacker News

Zig 0.4.0 Released

ziglang.org

121–130 of 141 posts

Re: Zig 0.4.0 Released

#121

Earlier quoted context omitted.

What is the actual argument that you support with pointing out that Zig is "largely single contributor"? Linux was largely a single contributor up to a point.

There is nothing wrong with single contributor languages. But for every C there are thousands of flatlined github repositories of single contributor languages. Building a language is a marathon, not a sprint. It takes years and years to grow something worthwhile, and this requires a lot of persistence. In the meantime, technical challenges, finances, family, and even busses get in the way of languages being fully rea…

Fun fact, I'm also training for a marathon! https://twitter.com/andy_kelley/status/1109906861241847816

There are 8 people on the Zig team, all with significant contributions and deep understanding of the project. https://github.com/orgs/ziglang/people

Re: Zig 0.4.0 Released

#122

Earlier quoted context omitted.

61 days ago you said [1] > Yes, I've done a terrible job with estimations and for 9 months I lived in "release tomorrow" mode. > Ironically this time it it really is going to be released tomorrow (Feb 7). [1] https://news.ycombinator.com/item?id=19102431

If you read the parent, it refers to Volt, and it was released.

I'm sorry, I was mistaken. That was incredibly rude of me.

I mistakenly assumed based on the title of the original post "About V, the language Volt is written in" that the post was about V, but as you pointed out, based on the parent comment it was actually about Volt.

I think I'm just excited to see your source code for V :-)

Re: Zig 0.4.0 Released

#123
Hooray for vector type. Language does not require operator overloads when math has proper first-class support. That's my favorite bike-shed color.

Re: Zig 0.4.0 Released

#124
post #59

I have one criticism: although zig has advertised very early on an amazing array of targets (probably taken from clang/llvm itself), some of the most esoteric ones have never worked for me, like powerpc (32bit) and MIPS. The blame is not entirely in zig but also in LLVM. It would be more fair to not even mention them as supported _at all_, or at the very least to document them as Tier 4.

I made that mistake before and I apologize for that. For this release cycle, I went through and tested creating a simple object file for all the targets, when categorizing them into tiers. So I think that if you try powerpc (32bit) and MIPS again you will find that they work now (probably because of LLVM improvements). If that is not the case, that is a bug and I would like to know about it.

Re: Zig 0.4.0 Released

#125
post #64

Earlier quoted context omitted.

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.

Wirth didn't produce anything usable before Oberon (which is garbage collected, so outside of the C niche.)

And yet despite of it doing everything that fits the niche http://www.projectoberon.com :-)

Re: Zig 0.4.0 Released

#126
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…

"Left-over artifacts from the OOP hype of the 90's". Sorry, but anyone that bashes on OOP can't be taken seriously. There's no problem with OOP, it can be misused of course, but the same is true of any other paradigm. Every programmer with any worth uses OOP, Functional, Data-Oriented, etc, where they are most effective. They are complements to one another not replacements.

Re: Zig 0.4.0 Released

#127

Earlier quoted context omitted.

Mainly because it seems like you constantly lie and make promises you can't keep. Some of your claims are outrageous without any evidence. Of course I would like to be proven wrong.

Can you give an example of my "constant lies" and outrageous claims?

Release dates have been consistently been pushed back for basically the last year. For months your program's website looked like it supported a lot of programs it didn't. Be clear and upfront about what you can do and people will trust you more.

Re: Zig 0.4.0 Released

#128
post #89

Earlier quoted context omitted.

JVM startup times are only an issue for those that don't want to buy a commercial JDK with AOT compiler support. Good news, now OpenJDK and GraalVM offer it for free, gratis. Object Pascal/Delphi is quite pratical on Windows.

> Object Pascal/Delphi It has a sane subset which is basically C with a slightly saner syntax than C (the begin...end and lacking data initialization syntax are terrible though!), and with a proper module system and much better compile times. On the other hand, it was crippled by missing a usable preprocessor and an ecosystem that has bought into each hype since the 90's, resulting in 23 incompatible kinds of strings…

Ah, one of those USENET posts.

Except for when I write Assembly, the last time I used raw goto on an high level language, my MS-DOS 5.0 box was still relatively new.

System.exit was always a thing to avoid namespace clashes and since Delphi 2009, you could have used System.exit(value) instead. Next time better read the docs.

Regarding strings, you mean like 8 bit, 16 bit, wchar_t, DBCS, GString and many others used across C libraries?

Nominal typing is much safer for large scale engineering than type aliases, which don't provide a mechanism to prevent incorrect usage of types.

Re: Zig 0.4.0 Released

#129
post #87

I'm surprised nobody is pointing out the similarities with Nim in terms of features: multiple targets (binary, js...), C interoperability, easy cross-compilation, metaprogramming, targeting many architectures, artifact caching.

If we look at it that way then OCaml should be on the list as well. :)

Re: Zig 0.4.0 Released

#130
post #128

Earlier quoted context omitted.

> Object Pascal/Delphi It has a sane subset which is basically C with a slightly saner syntax than C (the begin...end and lacking data initialization syntax are terrible though!), and with a proper module system and much better compile times. On the other hand, it was crippled by missing a usable preprocessor and an ecosystem that has bought into each hype since the 90's, resulting in 23 incompatible kinds of strings…

Ah, one of those USENET posts. Except for when I write Assembly, the last time I used raw goto on an high level language, my MS-DOS 5.0 box was still relatively new. System.exit was always a thing to avoid namespace clashes and since Delphi 2009, you could have used System.exit(value) instead. Next time better read the docs. Regarding strings, you mean like 8 bit, 16 bit, wchar_t, DBCS, GString and many others used a…

> System.exit was always a thing

Do you suggest I should use System.exit everywhere (even though all the code you find on the net uses just "exit")? Just to be sure that Delphi will never ever choose the wrong function to call WHICH IT SHOULD NEVER HAVE DONE IN THE FIRST PLACE OMG IT'S TOO FRIGGING COMPLICATED PLEASE DELPHI APPLY SOME COMMON SENSE.

It's beyond me why I should write a function call and incur symbol resolution for such basic control flow in the first place.

> the last time I used raw goto

I was mainly speaking about return, break, continue, which don't seem to be popular in Delphi. Examples of Delphi code that isn't a messy nesting fest? As for goto, there are perfectly valid uses for it, in fact some where goto is the clearest and most maintainable choice when you simply skip downwards over a chunk of code without requiring an extra flag.

> Regarding strings

I'm talking about the culture. The culture around C is not one that makes anti-modular "abstractions" (at least if you stay away from MS). You will never see me using wchar_t, GString or any of that god-awful Microsoft string mess. I get along just fine with only char. In fact, the string handling I get by using C is the most painless, most modular I've ever gotten in any language. (No, I don't want to use split() or use any other high-level stuff that would do allocations when that isn't necessary).

In Delphi, different story. Everything you find in this culture is built around String and AnsiString and UnicodeString and WideString and what not. Try googling how to access command-line parameters. The stuff is pervasive. Entirely different story.

> Nominal typing is much safer for large scale engineering than type aliases, which don't provide a mechanism to prevent incorrect usage of types.

Exactly, typealiases are bad. And now explain to me why Delphi forces me to make a type alias (for use in function signatures) when that is worse than immediate Pointer syntax in every conceivable aspect? (Having written a compiler I know the answer: because it requires less code in the compiler to check for type equality).

So I guess I should just avoid pointers altogether and use only GC'ed boxed OOP NOMINAL types. And finally have some time for coffee again while my application takes 5-10 minutes to start up (as it did before I reworked the thing), instead of 1 sec.

                end;
              end;
            end;
          end;
        end;
      end;
    end;
Post reply on HN