4 ms·

What about tools that statically analyze your code and allow you to be more productive? It may be possible to build more sophisticated and useful tools if the l

What about tools that statically analyze your code and allow you to be more productive? It may be possible to build more sophisticated and useful tools if the language is simple. You talk about giving the developer tools, but those tools can be augmentations on top of the basic building block that is the language. That way, anyone can build tools for their needs, without complicating the lives of others. No need to build all the tools into the language, that's very constraining.

pcwalton 9y ago
> What about tools that statically analyze your code and allow you to be more productive? It may be possible to build more sophisticated and useful tools if the language is simple. This is a thing that's commonly repeated, but it's not that, well, simple. Having a simple syntax doesn't matter that much for tools once you have a reusable parser library. More important for tools is having a simple semantics. Do all builtins behave the same way? Is nil handled consistently (e.g. does indexing a nil map do the same thing as indexing a nil slice)? Are the coercion rules simple? Is importing a package free of side effects? (The answer to all of these for Go, unfortunately, is no.) The most important thing, however, for tooling is whether the language provides static guarantees. For instance, if the language controls access to shared mutable state, you can do a lot to detect races statically. As another example, if panics were part of the type system, then you could statically know whether functions panic and, if so, what types of panics can happen. Here, Go provides very few static guarantees: it's very difficult to soundly prove anything interesting about Go programs. Unfortunately, you can't really have it both ways: you can have a more dynamic type system that doesn't put many constraints on on programs, or you can have interesting static tooling. Go chose the former in nearly every instance.
- e3b0c 9y ago
  But given the reality I observe, Go has already the top-tier tooling regarding IDE support and we are still waiting for the first production-ready RLS. Not that Go has the fanciest IDE products in the market or those tools have been invested heavily for Go, but it is obvious to me that such tools are abundant in the Go ecosystem that can be readily employed by every editor vendor. To put it in an ironic way, assuming same popularity, I think a quality language tool for Rust has more potential to be monetized (just like those for C++) than those for Go, because the former has much higher barrier to entry and hence less competitors.
  - pcwalton 9y ago
    We aren't talking about autocompletion. The post upthread describes "the tools to ensure...data integrity": i.e. type system or static analysis features to prevent bugs. That said, if you're trying to argue that autocompletion is more difficult to implement for Rust compared to Go because Go is simpler by some metric, then I disagree there too. Any static language (well, one that doesn't intertwine parsing and semantics like C++ does) can support autocompletion with comparable levels of implementation effort.
    - e3b0c 9y ago
      Then I am curious about what makes RLS or the alike so hard to onboard? Common IDE features like reliable and responsive "jump to definition", "Find all references" and "Renaming symbols" are 90% of all I would ask for. Do Rust devs have less attention to the area?
      - steveklabnik 9y ago
        Those three things already work in the RLS. And more: https://www.ncameron.org/blog/what-the-rls-can-do/ https://www.ncameron.org/blog/what-the-rls-can-do/
        mswift42 9y ago
        Is there an editor that supports jump to definition for macros?
        steveklabnik 9y ago
        I don't know. I have a hunch that lots of macros still will be better with the new macro system, but we'll see. Anyway, regardless, there's certainly more work to do! And it's being actively developed quite heavily. For example, it will be on stable Rust very soon.
        9y ago

pcwalton 9y ago

> What about tools that statically analyze your code and allow you to be more productive? It may be possible to build more sophisticated and useful tools if the language is simple. This is a thing that's commonly repeated, but it's not that, well, simple. Having a simple syntax doesn't matter that much for tools once you have a reusable parser library. More important for tools is having a simple semantics. Do all builtins behave the same way? Is nil handled consistently (e.g. does indexing a nil map do the same thing as indexing a nil slice)? Are the coercion rules simple? Is importing a package free of side effects? (The answer to all of these for Go, unfortunately, is no.) The most important thing, however, for tooling is whether the language provides static guarantees. For instance, if the language controls access to shared mutable state, you can do a lot to detect races statically. As another example, if panics were part of the type system, then you could statically know whether functions panic and, if so, what types of panics can happen. Here, Go provides very few static guarantees: it's very difficult to soundly prove anything interesting about Go programs. Unfortunately, you can't really have it both ways: you can have a more dynamic type system that doesn't put many constraints on on programs, or you can have interesting static tooling. Go chose the former in nearly every instance.

e3b0c 9y ago
But given the reality I observe, Go has already the top-tier tooling regarding IDE support and we are still waiting for the first production-ready RLS. Not that Go has the fanciest IDE products in the market or those tools have been invested heavily for Go, but it is obvious to me that such tools are abundant in the Go ecosystem that can be readily employed by every editor vendor. To put it in an ironic way, assuming same popularity, I think a quality language tool for Rust has more potential to be monetized (just like those for C++) than those for Go, because the former has much higher barrier to entry and hence less competitors.
- pcwalton 9y ago
  We aren't talking about autocompletion. The post upthread describes "the tools to ensure...data integrity": i.e. type system or static analysis features to prevent bugs. That said, if you're trying to argue that autocompletion is more difficult to implement for Rust compared to Go because Go is simpler by some metric, then I disagree there too. Any static language (well, one that doesn't intertwine parsing and semantics like C++ does) can support autocompletion with comparable levels of implementation effort.
  - e3b0c 9y ago
    Then I am curious about what makes RLS or the alike so hard to onboard? Common IDE features like reliable and responsive "jump to definition", "Find all references" and "Renaming symbols" are 90% of all I would ask for. Do Rust devs have less attention to the area?
    - steveklabnik 9y ago
      Those three things already work in the RLS. And more: https://www.ncameron.org/blog/what-the-rls-can-do/ https://www.ncameron.org/blog/what-the-rls-can-do/
      - mswift42 9y ago
        Is there an editor that supports jump to definition for macros?
        steveklabnik 9y ago
        I don't know. I have a hunch that lots of macros still will be better with the new macro system, but we'll see. Anyway, regardless, there's certainly more work to do! And it's being actively developed quite heavily. For example, it will be on stable Rust very soon.
        9y ago