3 ms·
This page seems only halfway there. These are not quite terminal arguments. No hidden allocations, standard lib is optional, simplicity - all cool! But the ques
by spenczar5 3y ago
This page seems only halfway there. These are not quite terminal arguments. No hidden allocations, standard lib is optional, simplicity - all cool! But the question is, when are those the right tradeoffs?
For example, I could see these being attractive in embedded work. I could see the simplicity becoming a headache in other contexts, like making abstracted all-purpose numerical libraries a la Eigen.
Maybe I am wrong about those particulars! But I would like the arguments completed: Zig has X distinctive features, which you should prefer if you do Y.
This is relevant to my interests right now: I am working on scaling up some scientific algorithms for astronomy research which have been well prototyped in Python, but which need to be faster. I am currently, unhappily, doing my work in C++ after abandoning Rust for being too immature in its CUDA and SIMD support, while also feeling pretty complex. Would Zig do well enough for me? I want a little more ink on the page to help me think this through.
- reactordev 3y agoI think the opinions on how a language is used should be left to the developer of in question. If zig said "Zig has X distinctive features, which you should prefer if you do Y" would alienate everyone doing Z and C and D. If ruby did that, we would never have rails. "Ruby has easy coding features, which you should prefer if you do scientific programming". Rails wouldn't exist. So, read the article and determine - "Does Zig with X features solve my use case of me trying to build Z after trying with Y"?
- deleted 3y ago[deleted]