281–290 of 307 posts
This is also why I struggle to answer the question "is it hard". Is it hard to build a web-app? No. But I've been building web-apps for 20 years. Will you find it hard (if you've never programmed before)? I don't know, if you want to build one this weekend, sure. If you have the patience to spend a few years learning first, then no.
Earlier quoted context omitted.
> I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving. > It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected…
> but it also removes the case of hacking up something in 10 days and suffering the consequences for the next 30 years Ha, I thought this sounded distressingly familiar! "In September 1995, a Netscape programmer named Brandan Eich developed a new scripting language in just 10 days. It was originally named Mocha, but quickly became known as LiveScript and, later, JavaScript."
Earlier quoted context omitted.
I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0
> I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving. > It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected…
Earlier quoted context omitted.
It's significantly nicer to write than C (my opinion obviously). I see it as a general purpose language. But mostly the team decided to do this because we wanted to unify on one language and double down on the investment in Zig. I'm not a fanboy (nothing wrong if anyone is, just clarifying about myself); I think this choice was right.
I guess I don't see C as programming language for writing scripts in either. In my view any language that requires a separate complication step is not a scripting language, and therefore not a language in which one writes scripts. In C or Zig you write programs. Maybe I am just being too pedantic.
Earlier quoted context omitted.
how your experience with Odin so far? How Odin differ from Zig in your opinion? What you likes/dislikes compared to Zig or other languages?
I think Odin is terrifically designed overall. There are design choices that I was initially very skeptical about but when I decided to use the language they actually made a lot of sense. Some overall differences between Odin and Zig and how I relate to them are: ## Exhaustive field setting Zig requires you to set every field in a struct. Everything everywhere has to be initialized to something, even if it's `undefin…
Did you encounter memory bugs? Essentially what memory safety feature Odin offer? (From what I read here, Zig and Rust offer some features to eliminate entire classes of bugs which remove the nightmare of hours of debugging)
Anything you dislike or wish Odin has that other languages offer?
>that the debug info situation seems much improved in comparison to 2022 when apparently it was much less complete (DWARF info, that is, PDB info seems to have been much better overall, historically).
I believe Odin was developed on windows and other system come later, probably that why PDB is much better.
I've now written a lot of zig code (http.zig, websocket.zig, log.zig, zuckdb.zig, etc.) I think Zig falls into an "easy to learn, average/hard to master" category. Some insiders underestimate the effort required for newcomers to build non-trivial things. I think this is because some of that complexity has to do with things like poor documentation, inconsistent stdlib, incompatible releases, slow release cycle, lack o…
I just start to learn Zig,any suggest to beginners?Bro
https://zigbyexample.github.io/
Their coverage is not very broad (in comparison to eg. Go by Example), but might be enough to get yourself started.
Earlier quoted context omitted.
First of all that only works with vectors, but I want operator overloading to also work on things like matrices or custom types (for example quaterions, or a symmat3 struct that represents a symmetric 3x3 matrix using only 6 floats). Additionally, for efficient math code you often want vector / matrix types in AOSOA fasion: for example Vec3 to store an AVX lane for each X/Y/Z component. I want vector/matrix operation…
I have a marvelous proof that you can solve that with comptime but unfortunately the margins of this website are too small to contain it.
Earlier quoted context omitted.
I think Odin is terrifically designed overall. There are design choices that I was initially very skeptical about but when I decided to use the language they actually made a lot of sense. Some overall differences between Odin and Zig and how I relate to them are: ## Exhaustive field setting Zig requires you to set every field in a struct. Everything everywhere has to be initialized to something, even if it's `undefin…
Thank you so much. It look like Odin is really a beautiful language to program with. Did you encounter memory bugs? Essentially what memory safety feature Odin offer? (From what I read here, Zig and Rust offer some features to eliminate entire classes of bugs which remove the nightmare of hours of debugging) Anything you dislike or wish Odin has that other languages offer? >that the debug info situation seems much im…
Odin is essentially in the same ballpark as Zig in terms of general safety features. Slices make dealing with blocks of things very easy in comparison to C, etc., and this helps a lot. Custom allocators make it easy to segment your memory usage up in scopes and that's basically how I deal with most things; you very rarely should be thinking about individual allocations in Odin, in my opinion.
> Anything you dislike or wish Odin has that other languages offer?
I would say that in general you have to be at least somewhat concerned with potential compiler bugs in certain languages and Odin would be one of them. That's not to say that I've stumbled on any interesting compiler bugs yet, but the fact that they very likely do exist because the compiler is a lot younger than `clang` or `gcc` makes it something that just exists in the background. Multiply that by some variable amount when something is more experimental or less tried and true. The obvious example there is the aforementioned debug info where on Linux this has been tried less so it is more likely to be worse, and so on.
In an ideal (fantasy) world I'd love something like type classes (from Haskell) in Odin; constraints on generic types that allow you to write code that can only do exactly the things expressed by those constraints. This gives you the capability to write code that is exactly as generic as it can logically be but no more and no less. Traits in Rust are the same thing. With that said, I don't believe that neither Haskell nor Rust implements them in a way that doesn't ruin compile time. Specialization of type classes is an optimization pass that basically has to exist and even just the fact that you have to search all your compiled code for an instance of a type class is probably prohibitively costly. It's very nice for expression but unless Odin could add them in a way that was better than Haskell/Rust I don't think it's worth having.
I would like to see how uniform function call syntax would work in Odin but this is actually addressed in the FAQ here: https://odin-lang.org/docs/faq/#why-does-odin-not-have-unifo...
UFCS works really well in D but D also has ad-hoc function overloading whereas Odin has proc groups. I think UFCS only really works with exceptions as well, so I think it can become awkward really fast with the amount of places you want to return multiple values where your last one represents a possible error.
Earlier quoted context omitted.
Zig does not have anything analogous to constinit, because Zig does not have object lifetimes or constructors. Comptime is also a massive pain to use for generating new data types (you have to return a type from a comptime function), and it cannot express anything analogous to CRTP.
I personally find returning a type from a comptime function to be quite elegant. Template parameters and regular parameters are unified into a single concept. Zig's comptime is analogous to constinit, because it lets you compute a value at compile time and ensure that it is linker-initialized into the final binary image. The point about CTRP is interesting, I'd have to think about that some more.
EDIT: Oh, I think I see how it's like `constinit`. If you have a non-`comptime` variable that is initialized by a `comptime` function, then it's a non-constant constant-initialized variable.