Hacker News Reader

Comment by kvark | Hacker News Reader

That “.” substitution of an inferred type is going to fire back. I really appreciate when code has one simple property: you search a type by name and you get all of the places where it’s constructed. Makes it easy to refactor the code and reason about it with local context. It’s the case with Rust, but not C++ or Zig.

View on HN

Any IDE worth its salt will let you search a type by name and get all the places where it's referenced, regardless of type inference.

A language that promotes itself as simple and with no hidden control flow etc shouldn't need an IDE to find hidden things imho.

But that kind of shortcut seems to be optional.

"No hidden control flow" is completely orthogonal to "no implicit typing". I think anyone looking at Zig would immediately recognize that it is firmly in the type inference camp by choice.

As far as simplicity, I think their pitch is "simpler than Rust", not in absolute terms. The whole comptime thing is hardly simple in general.

Their pitch is "A Simple Language" as seen on the website.

I think it is simple, but not easy to grasp. I might be quibbling over words, but these things are not quite the same in my eyes.

  simple <-> complex
    easy <-> difficult

I know this gets shared all the time, but in case anybody in this thread hasn’t seen the rich hickey talk: https://youtu.be/SxdOUGdseq4?si=3sa6JRg6Ei1Cf_Wl

I am not a big Zig aficionado but I definitely contrast it in my mind moreso with C and C++ rather than Rust. It definitely aims at being a “better C” sort of language moreso than a “better C++” which Rust seems to be focusing on.

Better than that would be a language that doesn't require / almost compel users (by "almost compel", I mean the user community, obviously, not the language literally, since it is not sentient) to use an IDE in order to use the language, and using which (language) you can still do what you said above, by just using a text editor.

In the same vein as what you said here about orthogonality ( https://news.ycombinator.com/item?id=42097347 ), programming languages and IDEs should be orthogonal (and actually are, unless deliberately linked). People were using languages much before IDEs existed. And they got a hell of a lot done using the primitive surrounding tools that existed back then, including, you know, gems like Lisp and the concepts embodied in it, many of which have, much later, been adopted by many modern languages.

And I still meant "almost compel", even by the community, because of course they cannot really compel you. I meant it in the sense of, for example, so many people using VS Code for programming posts.

> Better than that would be a language that doesn't require / almost compel users (by "almost compel", I mean the user community, obviously, not the language literally, since it is not sentient) to use an IDE in order to use the language, and using which (language) you can still do what you said above, by just using a text editor.

It's ironic that you complain about this because Zig is probably the most "normal editor" friendly programming language for exactly the kind of thing mentioned in the article.

I don't need an IDE to figure out the 12 options to that function and fill them out with the correct defaults. I don't have to hunt through 23 layers of mysterious header files to find the declaration I need to figure everything out. etc.

Just try figuring out a foo(12).bar(14).baz("HELP!").fixme("ARRGH!") construction chain in C++ or Rust without an IDE. Oof.

1) Zig doesn't encourage those and 2) in Zig I can trace the @import() calls and actually run "grep" on things.

>It's ironic that you complain about this because Zig is probably the most "normal editor" friendly programming language for exactly the kind of thing mentioned in the article.

echo Who complained, $(echo bsder | sed 's/sd/ro/') ? ;)

Not me. Don't put words into my mouth.

(I don't care if I got the above shell syntax wrong), this was just a quickie, for fun ;)

you seem to have misunderstood my words, in the exact opposite way from what I meant. congrats. not!

>I don't need an IDE

who told you that I needed an IDE?

chill, willya?

and, wow:

>to figure out the 12 options to that function and fill them out with the correct defaults. I don't have to hunt through 23 layers of mysterious header files to find the declaration I need to figure everything out. etc.

12 and 23, exaggerating much? we are not talking about win32 API functions, podner.

>Just try figuring out a foo(12).bar(14).baz("HELP!").fixme("ARRGH!") construction chain in C++ or Rust without an IDE. Oof.

Don't resort to theatrics or histrionics to make your point (like HELP! and ARRGH!), (I am allowed to, tho, because i > u :)

>1) Zig doesn't encourage those and 2) in Zig I can trace the @import() calls and actually run "grep" on things.

faaakkk!

though a bsder, you find header files mysterious, and cannot grep through them, if they are in C++ or Rust, eh? are find and xargs your enemies? or even just ls - R | grep ?

stopped editing, even though there might be a few minor typos.

now, fire back! :)

This doesn't cover every use case (e.g, reviewing a PR and just trying to - you know - read the PR).

Does Zig have an IDE worth its salt?

Zig does not have an IDE, but it does have a language server called zls[0] that I have found to be pretty decent after implementing Loris' suggestion from this post[1].

[0] - https://github.com/zigtools/zls

[1] - https://kristoff.it/blog/improving-your-zls-experience/

I'm using InteliJ with a Zig plugin and finding it quite nice. But I'm a Zig noob

An easy way to find all places is to temporarily add a new struct member without defaults, run the compiler and let it complain of all the places where it is being instanced.

Similar to when you add a new enum member and it complains of all switch statements that are not using it (as long as you didn't add a default case).

This is tedious in Rust when initializing a struct which has nested structs. A language which has type inference at all should at least be consistent about it and allow to not mention the type when it can be inferred by the compiler.

What's meaningfully different in Rust's type inference. E.g.:

  fn example() {
      let p = returns_a_point_type(args);
  }

Where create_point() is a function from a module (e.g. not even defined in that file) which returns the Point type automatically inferred for p? I mean sure, it's technically constructed in the called function... but is that often a useful distinction in context of trying to find all of the places new instances of types are being assigned? In any case, this is something the IDE should be more than capable of making easier for you than manually finding them anyways.

GP is talking about how easy it is to find places where the type is instantiated. Seems to me that create_point() will have one such site. And then it’s trivial to find callsites of create_point() with the LSP/IDE. What’s the issue?

The IDE can find all places new variables are assigned to the type (regardless of whether it's direct instantiation, return value, inferred, or whatever way it comes about) so what's the special value of being able to manually find only the local instantiations find ctrl+f if you'd still need to manually track down the rest of the paths anyways?

Reply on news.ycombinator.com