91–100 of 130 posts
I hope Zig adds complex numbers before it is too late. It's a pity that they did not steal array syntax and slices from Fortran/Numpy.
What about quaternions, or vectors and matrices of sizes 2-4 at least?
Is there any real advantage over just using a struct?
Would MultiArrayList help with performance for complex numbers and vectors?
Earlier quoted context omitted.
It appears to me it could become the low level language of choice for small embedded systems in contexts where Lua or MicroPython couldn't fit the bill performance-wise and one wants something higher level than C. Ditto for Nim and Crystal.
It’s constraints on memory management basically will never allow that to happen. It lures people in with “use any allocator you want”! Which only appears as freedom of choice when reality it’s locking the user into the same paradigm of memory management that has given C a bad name to begin with.
I hope Zig adds complex numbers before it is too late. It's a pity that they did not steal array syntax and slices from Fortran/Numpy.
Why would complex numbers in particular deserve to be a native type? What about quaternions, or vectors and matrices of sizes 2-4 at least? Is there any real advantage over just using a struct? Would MultiArrayList help with performance for complex numbers and vectors?
One of the features missing in bun:ffi is inferring types for symbols from header files. This would let you import C libraries in JavaScript/TypeScript directly, without having to configure bindings. We embed TinyCC for FFI, but TinyCC doesn't expose a way to read the types for exported symbols. Currently, it looks like this: import { dlopen, FFIType, suffix } from "bun:ffi"; // `suffix` is either "dylib", "so", or "…
With D it is: import sqlite3; This causes sqlite3.h to be read, lexed, parsed, and semantically analyzed to convert (where possible) C symbols to D symbols, and makes them available to the importer. I've been sometimes pressured to instead use various more complicated syntaxes, but have held the line :-)
import c = sqlite3;
import c = sqlite3, miniz;Wait, so you still need zig, and zig still needs LLVM. If you have LLVM, you have clang. What is the value proposition of this compiler, then?
Zig helps a lot, but in comparison, Aro is small, and simple to understand and maintain.
I hope Zig adds complex numbers before it is too late. It's a pity that they did not steal array syntax and slices from Fortran/Numpy.
I'm curious, what use cases do you have for complex numbers that couldn't be provided in a 3rd party library or maybe even the stdlib?
Earlier quoted context omitted.
Let me just say, your comments have not been the most constructive I’ve read.
Sure, I will let you say it :) Let me say that I think the same about this comment of yours upthread: >>D would deserve attention too, in a separate post, or here if it was explained how it relates to Aro. In case you cannot or don't want to google for some reason, here are the Wikipedia articles about D, Walter and Andrei, and important related topics (all on Wikipedia, which implies notability) that I suggested you…
I hope Zig adds complex numbers before it is too late. It's a pity that they did not steal array syntax and slices from Fortran/Numpy.
Why would complex numbers in particular deserve to be a native type? What about quaternions, or vectors and matrices of sizes 2-4 at least? Is there any real advantage over just using a struct? Would MultiArrayList help with performance for complex numbers and vectors?
I hope Zig adds complex numbers before it is too late. It's a pity that they did not steal array syntax and slices from Fortran/Numpy.
Why would complex numbers in particular deserve to be a native type? What about quaternions, or vectors and matrices of sizes 2-4 at least? Is there any real advantage over just using a struct? Would MultiArrayList help with performance for complex numbers and vectors?