Hacker News Reader

Comment by kreco | Hacker News Reader

Could you describe briefly what feature you are sorely missing?

I like the language intention but I can't get past the syntax.

For me it's all comptime stuff and it's kind of arbitrary things like parsing out the type information of a function doesn't include the name of the function parameters, but basically everything else that has a name has that information present in their info structure. The other thing is tags, being able to tag things that I can parse at compile time. I'm making something close to a database orm, (specifically it's spacetimedb, thought it'd be fun to use zig with). But information about things like primary keys, auto increments, constraints and similar all has to live in a different structure completely untied to the original struct or function. I'd like to be able to tie those things together easily to avoid mistakes and confusion. I have different workarounds that I've tried, but nothing that's universal for all my test cases.

For syntax there are a few things that I'm iffy on, but nothing that I'd consider a deal breaker. I found it very easy to read right out of the gate, which is basically the only thing I need to really learn a new language (probably the only reason I haven't learned rust yet.)

Thanks for the reply.

I totally understand how those two features could be useful.

For the parameter name feature, I can't imagine a strong reason for not implementing it (I mean, apart of "we have other stuff to prioritize").

For the tag I could see an attribute system like in C++ [0]

On a tangential topic, I believe that's exactly the Pandora box of meta-programming.

[0] https://en.cppreference.com/w/cpp/language/attributes#Explan...

I think at one point they rejected the idea, but I think it was from 2018 or so. The cpp attributes does seem like what I'd want, but yeah c++ compile time code isn't good enough for what I need.

Wouldn't you be happy if you could add attributes to functions,members etc (and obviously analyze them at compile time)?

Just wanted to say that Rust may look strange early on but very, very quickly becomes entirely natural, so don't let that be the reason why you haven't learned it is my unsolicited input

Yeah, I just haven't needed the memory safety that comes with it and I don't have the same gripes everyone else has with c's include system. At this point it just doesn't have anything to offer that I really care about. I only learned zig because of the comptime stuff and some ease of use when it came to tls encryption. I'm a little interested in rust macros, but that's really it and I don't think that's enough to learn a new language. I'm sure I'll eventually have a project where memory safety (with speed) is a priority, but to this point it's just never come up at work or the projects I work on in my free time.

I hear you, people have different preferences and rank their preferences in different order.

For what it's worth, I use Rust daily and I don't really care about memory issue. It's nice that it comes with the package, but it's not why I do it. Believe it or not, the borrow checker is first and foremost why I enjoy writing Rust. It's such a brilliant idea I don't understand why it's not more widely used. A helpful compiler and a good (if imperfect) crate ecosystem are probably 2nd and 3rd.

Syntax is so much less important that semantics that it isn’t even really worth talking about in my opinion

Readability (in the sense of "How fast can the average developer parse code in the given language?") and proneness to errors are a thing, though.

Consider, e.g., how in TypeScript object literals ({ a: b, c: d, e }), object types ({ a: b; c: d; }) and object destructuring ({ a, c, e } = … ) can all look very similar. Same thing for lambdas ((a: b) => b) and function types ((a: b) => b). Also, additional parentheses are needed to prevent the compiler from mistaking an object literal ({ … }) for a function body ({ … }) when it is returned in a lambda expression. In short: Some of TypeScript's syntactic constructs are heavily overloaded and their meaning depends on the context.

For an example of proneness to errors, consider that in Nix function calls (<function name> <param1> <param2> …) and lists ([<item1> <item 2> …]) look almost the same and it's very easy to confuse the two and mess up, e.g.

``` let foo = [ item1 myFunction "arg1" "arg2" item3 ] ```

defines a list with 5 items, not 3, due to missing parentheses around the function call.

Sure but I don’t think those examples really matter once you establish basic familiarity with a language. The semantics and constructs a language provides are much more important and debating syntax is missing the forest for the trees

The array syntax is very offensive: `const a = [3]i32{ 1, 2, 3 };` A set is denoted by braces, not an array.

1. using [] drops context-freeness. what is: foo[1]? is that foo type array with one element? or accessing the foo array at index 1?

2. how do you feel about array initialization in C?

3. you can think of {...} as defining memory regions, curlies around code are defining "a memory block of instructions"

According to your familiarity yes, but how is this such a problem? It’s easy to get past

Yes it is according my familiarity, but set notation has been the same since the 1870s, why should this language fuck it up? Rust does it correctly.

This is exactly why I find the language unintuitive. I don't understand why they made the choices they made. For example, why curly brackets?

I find the rust equivalent much more intuitive `let a: [i32; 3] = [1, 2, 3];`

It’s targeting C/C++ programmers accustomed to initializer lists in C/C++.

you couldn't do that in zig because a type is potentially a valid value:

.{i32, 3} is a valid term in zig.

Reply on news.ycombinator.com