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

Zig: The Modern Alternative to C

infoworld.com

Post reply on HN
Print view View original

161–170 of 181 posts

Re: Zig: The Modern Alternative to C

#161

Post by gpderetta »

oriolid wrote: post #147
gpderetta wrote: post #139

Earlier quoted context omitted.

Ah, that's a trick question. There is no typical OOP definition of object. I used to think that only aspect everybody agrees on is late binding, but some people consider traits-like static binding a form of OOP.

Well, you brought up the subject :) I think it's a bit intellectually dishonest to appeal to typical OOP definition when there isn't one (except that your language isn't true OOP but my language, I won't tell which one, is). And there are quite a few different definitions of late binding too.

There are multiple contradicting definitions of OOP, but I don't know any that would include C POD types and primitives.

Re: Zig: The Modern Alternative to C

#162

Post by messe »

humanrebar wrote: post #158
messe wrote: post #153

Earlier quoted context omitted.

Just because it’s the default doesn’t mean it’s the only option. Another approach would be to integrate your zig code as a static library, and have your existing build system call out to zig’s build system just for that part of the build. Linking it to the rest of your code could then be performed by your existing build system, just as it would link any other library. In practice, Zig is quite flexible.

I'd like that plan a lot more if there were any normal way for build systems to communicate about build requirements and outcomes and the zig toolchain implemented it.

That’s as much make’s fault as Zig. You can go further and eschew the zig build system, using `zig build-lib`, I’d that helps.

Re: Zig: The Modern Alternative to C

#165

Post by nsajko »

firstlink wrote: post #145
nsajko wrote: post #76

Earlier quoted context omitted.

Iterators are often nice, but are no replacement for loops. Try processing multidimensional arrays without loops.

> iterators > without loops This is a false dichotomy. You can use iterators to replace three-clause loops without changing the body: for row in 0..rows { for col in 0..cols { arr[row][col] } } This is far easier to read than three-clause loops which repeat redundant information repeatedly and redundantly.

OK, but you're still using loops.

Re: Zig: The Modern Alternative to C

#166

Post by proto_lambda »

nsajko wrote: post #165
firstlink wrote: post #145

Earlier quoted context omitted.

> iterators > without loops This is a false dichotomy. You can use iterators to replace three-clause loops without changing the body: for row in 0..rows { for col in 0..cols { arr[row][col] } } This is far easier to read than three-clause loops which repeat redundant information repeatedly and redundantly.

OK, but you're still using loops.

You are, but that was never in question.

Re: Zig: The Modern Alternative to C

#167

Post by oriolid »

gpderetta wrote: post #161
oriolid wrote: post #147

Earlier quoted context omitted.

Well, you brought up the subject :) I think it's a bit intellectually dishonest to appeal to typical OOP definition when there isn't one (except that your language isn't true OOP but my language, I won't tell which one, is). And there are quite a few different definitions of late binding too.

There are multiple contradicting definitions of OOP, but I don't know any that would include C POD types and primitives.

The original claim was that C++ "objects" and C PODs and primitives are the same. It's a rather odd claim, and the questions whether C++ "objects" are true objects, there is even a definition of true object, or was object oriented programming a good idea to begin with, don't seem to be closely related.

Re: Zig: The Modern Alternative to C

#168

Post by gpderetta »

oriolid wrote: post #167
gpderetta wrote: post #161

Earlier quoted context omitted.

There are multiple contradicting definitions of OOP, but I don't know any that would include C POD types and primitives.

The original claim was that C++ "objects" and C PODs and primitives are the same. It's a rather odd claim, and the questions whether C++ "objects" are true objects, there is even a definition of true object, or was object oriented programming a good idea to begin with, don't seem to be closely related.

The standard definition definition of Object in C++ is the same as the definition of Object in C because the standard says so: https://en.cppreference.com/w/cpp/language/object .

Is not a problem of interpretation. It is just that the C standard uses the term object for just a bunch of memory (with a type) and the C++ standard does so too. Nothing to do with objects in the OOP sense.

Re: Zig: The Modern Alternative to C

#169

Post by thdespou »

pron wrote: post #84
Animats wrote: post #19

That article is about control flow and syntax, which isn't a big problem. What matters is data. So what does Zig have that C doesn't? - Arrays and slices. A slice is a pointer and a length. There's subscript checking on slices. You'd expect that the preferred operation would be to take a slice from a slice, but the documentation does not mention that option. This may be a documentation error. There is a ".." operator…

Sometimes what's most important is not what you have but what you don't have. Zig doesn't have preprocessor macros; it doesn't have dangerous C-like unions (unless explicitly requested via "unsafe" constructs). Pointer arithmetic and casts are explicitly delineated as unsafe constructs, and are more easily avoided. What this means is that (unless the clearly demarcated "unsafe" constructs are used) all pointers in a…

It's not only low level. I think it can compete with Go in many areas.

Re: Zig: The Modern Alternative to C

#170

Post by blacksqr »

hawski wrote: post #54
rahen wrote: post #39

Earlier quoted context omitted.

I would be interested in hearing more about your point. TCL is an elegant scripting language, very LISP-y, where most data structures are lists of strings. Go on the other hand is more like a modern mix of C and Pascal with GC and lots of convenient libraries, and which builds statically. The performance of TCL and Go are also a world apart.

I am pulling a leg here a bit. I could risk a statement that Tcl could be an alternative when all you want is a simple CRUD backend. Now performance considerations are valid, but in some applications Tcl could be fast enough. Both languages, or maybe we could say platforms, have manged runtimes and maybe that's were similarities end.

Tcl is good for both CRUD and REST; for example, the sqlite.org web site uses a pure Tcl web server, through which you can access sqlite's SCM app which is backed by a SQLite database.
Post reply on HN