4 ms·

I am unsure what you mean. Care to elaborate?

conaclos 4y ago
See my other answer [1] to get more context :) [1] https://news.ycombinator.com/item?id=33729406 https://news.ycombinator.com/item?id=33729406
TheCycoONE 4y ago
I think I followed. One aspect of a programming language is how easy it is to build a useful IDE for with code prediction, navigation, refactoring, etc. Java is relatively easy, Lua is very hard. Rust is somewhere in the middle, with macros being a complicating factor. https://rust-analyzer.github.io/blog/2021/11/21/ides-and-macros.html https://rust-analyzer.github.io/blog/2021/11/21/ides-and-mac... discusses the problems specific to rust much better than I could.
- bitexploder 4y ago
  Go has one of the best compiled language IDE experiences out there. GoLand makes it feel easier than Python code :)
  - zaphirplane 4y ago
    Can it find all Implementations of an interface or what interfaces this implements ?
    - bitexploder 4y ago
      Yes to both. It is great :)
mvhvv 4y ago
I'm unsure exactly what the above poster is trying to say, I generally find Rust development very pleasant with nothing but vscode and Rust-analyzer. But... I'll admit there is one major stumbling block so far. Debugging iterator chains can be cumbersome because of the disconnect between the language and the compiled code. I've found myself stepping in and out of assembly more than I'd like. I assume this is the kind of problem that can be overcome with a nicer debugger though.
- still_grokking 4y ago
  > I assume this is the kind of problem that can be overcome with a nicer debugger though. I think this would be something that modern debuggers need to solve somehow in general. There are more and more languages with high amount of syntax sugar, where the output to be debugged doesn't have much in common anymore with the code written. Debuggers need to be aware of desugarings somehow. But it makes no sense to implement this on a case by case basis for every language. We need next generation debuggers! (But I have no clue how "a sugar aware debugger" could be implemented; something in the direction of "source maps" maybe?)

See my other answer [1] to get more context :) [1] https://news.ycombinator.com/item?id=33729406 https://news.ycombinator.com/item?id=33729406

TheCycoONE 4y ago

I think I followed. One aspect of a programming language is how easy it is to build a useful IDE for with code prediction, navigation, refactoring, etc. Java is relatively easy, Lua is very hard. Rust is somewhere in the middle, with macros being a complicating factor. https://rust-analyzer.github.io/blog/2021/11/21/ides-and-macros.html https://rust-analyzer.github.io/blog/2021/11/21/ides-and-mac... discusses the problems specific to rust much better than I could.

bitexploder 4y ago
Go has one of the best compiled language IDE experiences out there. GoLand makes it feel easier than Python code :)
- zaphirplane 4y ago
  Can it find all Implementations of an interface or what interfaces this implements ?
  - bitexploder 4y ago
    Yes to both. It is great :)

mvhvv 4y ago

I'm unsure exactly what the above poster is trying to say, I generally find Rust development very pleasant with nothing but vscode and Rust-analyzer. But... I'll admit there is one major stumbling block so far. Debugging iterator chains can be cumbersome because of the disconnect between the language and the compiled code. I've found myself stepping in and out of assembly more than I'd like. I assume this is the kind of problem that can be overcome with a nicer debugger though.

still_grokking 4y ago
> I assume this is the kind of problem that can be overcome with a nicer debugger though. I think this would be something that modern debuggers need to solve somehow in general. There are more and more languages with high amount of syntax sugar, where the output to be debugged doesn't have much in common anymore with the code written. Debuggers need to be aware of desugarings somehow. But it makes no sense to implement this on a case by case basis for every language. We need next generation debuggers! (But I have no clue how "a sugar aware debugger" could be implemented; something in the direction of "source maps" maybe?)