[kvark]

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.

[int_19h]

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.

[alpaca128]

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.

[Klonoar]

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

[fuzztester]

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.

[lmm]

Does Zig have an IDE worth its salt?

[rererereferred]

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).

[flohofwoe]

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.

[zamadatix]

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.

[nindalf]

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?