Move Zig. For great justice!
Take off every Zig!
Why is Zig so cool?
481–490 of 527 posts
Re: Why is Zig so cool?
#482Earlier quoted context omitted.
NOOOO! What Ada (and Rust) calls generics is very different -- it is like template functions in C++. In those languages the version of the function that is selected is based on the declared type of the arguments. In CLOS, Dylan, Julia the version of the function that is selected is based on the runtime type of the actual arguments. Here's an example in Dylan that you can't do in Ada / Rust / C++ / Java. define method…
You missed the way Ada does OOP, and went completely overboard talking about generics. As you can see from my comment history, I am quite aware of CLOS, Lisp variants and Dylan.
Last I checked, Ada does not have multimethods/generic functions in the sense of CLOS, Dylan and Julia. It has static function overloading, and single-argument dispatch, just like C++.
Re: Why is Zig so cool?
#483Earlier quoted context omitted.
Having spend a year tinkering in zig and it's absence of features has made me want to drop c#/java professionally and pick up Golang. Its quiet annoying when you see a codebases written in C#/java and you can tell in which year/era it was written because of the language features. The way of writing things in C# changes like every 4 years or so. There's a certain beauty in only having to know 1~2 loops/iteration conce…
You already have have Go, before and after modules, before and after generics, before and after ranges over function types. Skipping other minor changes. However I do agree C# is adding too much stuff, the team seems trying to justify their existence.
Thats true with Go but it feels those features are more rare. Compared to say what feels like almost yearly changes in C# to the point a lot of people think its overwhelming and it usually not clear how much of those features really add to the language and dev experience.
My experience with Golang so far is biased because i only recently looked at golang, for the past decade i have been working mostly in java and c#, so most of those newly added features in golang is stuff i'm already deeply familiar with conceptually.
Re: Why is Zig so cool?
#484Earlier quoted context omitted.
For anyone not familiar: You can bundle arbitrary software as Python wheels. Can be convenient in cases like this!
What "cases" are those? Tell me one useful and neat case. Why is it useful and neat, you think?
uv and ruff use that Approach. They are Python related tools, but written 100% in Rust.
Re: Why is Zig so cool?
#485I'm afraid this article kinda fails at at its job. It starts out with a very bold claim ("Zig is not only a new programming language, but it’s a totally new way to write programs"), but ends up listing a bunch of features that are not unique to Zig or even introduced by Zig: type inference (Invented in the late 60s, first practically implemented in the 80s), anonymous structs (C#, Go, Typescript, many ML-style langua…
When I read "I can easily say that Zig is not only a new programming language, but it’s a totally new way to write programs" I expected to see something as shocking as LISP/Smalltalk/Realtalk/EVE/FORTH/Prolog... A whole new paradigm, a whole new way to program. Or at least a new concept like the pure functionalism of Haskell, or Prototyping like in Lua/JS/Io. And I was so damn shocked how I must have missed something…
> Also turned out for no reason based on the comments.
The reason is the clickbait title.
Re: Why is Zig so cool?
#486Earlier quoted context omitted.
An example of Zig not having generics, interfaces, and macros? I don't understand.
The partial evaluation you mentioned.
I'm still not sure what exactly you're asking, but the implementation of print linked above (https://ziglang.org/documentation/0.15.2/#Case-Study-print-i...) typically requires some kind of syntactic macros in other lanugages as does something like "innerParse" here (https://ziglang.org/documentation/0.11.0/std/src/std/json/st...), this (https://ziglang.org/documentation/0.15.2/#Generic-Data-Struc...) would typically require some kind of a separate generics or templates feature in other languages, and to see how comptime replaces interfaces, search for "formatType" here: https://marcelgarus.dev/comptime.
Again, the novel use of partial evaluation in Zig is that it eliminates generics, interfaces, and macros. Any language that has one or more of these features does not have this novel design.
Re: Why is Zig so cool?
#487Yeah, big fan of zig here
Btw it's so much easier to add an environment variable in linux, I haven't used windows since 2007 so it was interesting for me to see how you do it there. Clicking on edit buttons to find that menu ? Nah, I don't do that here :)
Re: Why is Zig so cool?
#488Earlier quoted context omitted.
An example of Zig not having generics, interfaces, and macros? I don't understand.
@pron If all you mean is there is more syntax to D than to zig to achieve same/similar thing then you may be a bit aggresive on how you communicate it.
It's not about more syntax, it's about design, and how Zig was the first to use partial evaluation to do away with several, rather common, features.
It's like how the novelty of the iPhone's touchscreen design was in not having a keypad, or that the novelty of the spork wasn't in inventing the functionality of either the spoon or the fork, but in having a single utensil that performs both. The more important aspect isn't the functionality but the design. I'm not saying you need to like any of these designs, but they are novel.
Saying that you could have a similar functionality by other means misses the point as much as saying that there's nothing special about a spork because if you have a spoon and a fork, then you have the same functionality. But you still don't have a spork.
You could, then, ask what the point of the novel design is. Well, in some languages you have generics and interfaces and compile-time expressions, but because none of these is general and powerful enough, so you also have macros. Macros are very powerful - perhaps too powerful - but they are difficult to understand, so they're used sparingly even if they can subsume other functionality.
Zig has shown that you can do almost anything you would reasonably want to do with macros with partial evaluation that has access to reflection. That wasn't obvious at all. And because that feature was not only powerful enough to subsume other features and make them redundant, but also very simple and easy to understand, it ended up with a design that is both minimal and easy to read (which is important for code reviews) but also highly expressive. Again, you don't have to like this rather minimalistic design, but it is novel.
Re: Why is Zig so cool?
#489Earlier quoted context omitted.
You can write Objective-C and C++ in the same source file, even mixing them in the same line of code, and it compiles together, but no one can say these are not two very different languages.
The name Objective-C++ exists for a reason.
If you think Objective-C++ is a bonafide language in its own right rather than what it clearly is -- a convenience to use two very different languages together -- then there is no point trying to debate with you further.
Re: Why is Zig so cool?
#490> I can’t think of any other language in my 45 years long career that surprised more than Zig. I can say the same (although my career spans only 30 years), or, more accurately, that it's one of the few languages that surprised me most. Coming to it from a language design perspective, what surprised me is just how far partial evaluation can be taken. While strictly weaker than AST macros in expressive power (macros ar…
> hence its "zero-cost abstractions", made to give the illusion of a high-level language without its actual high-level abstraction What does this mean? For example (you can pick another example if you want), how is C++'s std::vector less abstract than Java's ArrayList?
Because std::vector isn't much of an abstraction, in the sense of removing a set of concerns from consideration. v[i] is just pointer math. What happens if you index outside the bounds of v is anybody's guess, and it can fail silently. You could use v.at(i), but then somebody will yell at you for using exceptions. Regardless of where you stand on C++ exceptions, the fact that it's up for debate means that it will get debated. The cost of zero-cost abstractions in C++ is quite high.