3 ms·

> if it's not, that's a problem to be fixed I agree, but it’s very expensive to fix. Visual Studio is a de-facto standard in many areas for a reason. > intero

> if it's not, that's a problem to be fixed I agree, but it’s very expensive to fix. Visual Studio is a de-facto standard in many areas for a reason. > interop between two languages causes more subtle issues that you don't notice I have some experience with python. C interop does work, but the usability is not OK. The languages and runtimes are just too different, which caused non-trivial amount of boilerplate to integrate the two. C# / C++ integration is much easier. I remember a few times when I wanted to move that interop boundary, usually in the direction of “less C++”, but did nothing about that because development overhead was too large. And I agree that’s harmful in the long run. Here’s a famous quote: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule The idea does apply to all sufficiently complicated programs ever since: MS Office has VBA, game engines have their scripting languages, AutoCAD has LISP, and so on. I’m pretty sure that if in the future some programming language gonna become good enough to rule them all, that language will be much closer to modern C# than to modern Rust. Rust offloads a huge amount of complexity to developers (being such a developer, I don’t like that) and to the compiler (results in slow builds).

lmm 6y ago
> I agree, but it’s very expensive to fix. Visual Studio is a de-facto standard in many areas for a reason. Well sure, and in reality IDE support is a big reason I'm using Scala rather than Haskell. But the fact is that there are maybe 2.5 good IDEs going, and that seems like as much as the programming industry can support. So either we accept that the only way to make your programming language experience any good is to get it picked up by one of the handful of giant companies that can fund those IDEs, or we have to be willing to at least start a promising language without an IDE and hope other advantages can make up for that shortcoming for some use cases, and eventually there'll be enough momentum that one of those giant companies will pick it up. I can't see what other way there is to advance the state of the art, unless your position is going to be that C# is perfect and there's no point trying to do better. > I’m pretty sure that if in the future some programming language gonna become good enough to rule them all, that language will be much closer to modern C# than to modern Rust. Rust offloads a huge amount of complexity to developers What complexity is that? I'd argue that the trait system is a noticeable improvement over what's available in C#, and not having exceptions makes code significantly easier to understand. On linearity I could go either way - in theory it's more work for the developer, but borrow-checker friendly code styles tend to just be good coding style. Most of the time I write the same code I'd write in C#, Scala, or anything else, and it just work - and when it doesn't either the error messages have been clear and the fix has been easy, or it became clear that I was genuinely very confused about the problem and needed to rethink my whole approach. (But yeah actually GC is fine 100% of the time and Scala is already the one language to rule them all, people just haven't realised yet)
- Const-me 6y ago
  > What complexity is that? First and foremost ownership shenanigans. The complexity spill over the entire ecosystem. You can't write a fizz buzz without discovering the standard library has 2 types of strings because of that. > not having exceptions makes code significantly easier to understand Both error codes and exceptions have their place. Imagine a streaming parser of some XML/JSON/mpeg4/whatever. There's nothing you can possibly do in the parser to handle socket errors. Exceptions make parser's code more readable, essentially you pretend sockets never fail. > confused about the problem and needed to rethink my whole approach No amount of rethinking gonna help when you need a graph data structure in your code. Ownership shenanigans making graphs complicated in Rust, fundamentally so.
  - lmm 6y ago
    > Imagine a streaming parser of some XML/JSON/mpeg4/whatever. There's nothing you can possibly do in the parser to handle socket errors. Exceptions make parser's code more readable, essentially you pretend sockets never fail. Disagree, because even if you can't handle errors in your code you have to do things like make sure resources are closed correctly. So you end up having to reason about exception safety, which is notoriously error-prone. If you have to have paths for propagating errors through your code, it's better to have them visible where you can reason about them, even if the actual handling has to take place at a different level. > No amount of rethinking gonna help when you need a graph data structure in your code. If you need a graph with cycles and you don't have a clear owner for the graph as a whole, sure. That's a pretty rare situation IME.
    - Const-me 6y ago
      > you have to do things like make sure resources are closed correctly. Not all code deals with resources. Streaming parsers normally don't. When you don't open/close any resources, manually propagating errors complicates code for no good reason. > a graph with cycles and you don't have a clear owner It's hard in Rust even for acyclic graphs with a clear owner, due to updates. Code that mutates the graph often needs to update multiple nodes at once, but Rust only supports a single writeable reference per object instance. All practical Rust implementations of graphs, trees and linked lists I saw use unsafe to workaround the fundamental language limitation. That's OK for linked lists because so simple and a standard library implementation is often enough. Graphs and trees however are very different based on use cases, can't implement just once and call it a day.

lmm 6y ago

> I agree, but it’s very expensive to fix. Visual Studio is a de-facto standard in many areas for a reason. Well sure, and in reality IDE support is a big reason I'm using Scala rather than Haskell. But the fact is that there are maybe 2.5 good IDEs going, and that seems like as much as the programming industry can support. So either we accept that the only way to make your programming language experience any good is to get it picked up by one of the handful of giant companies that can fund those IDEs, or we have to be willing to at least start a promising language without an IDE and hope other advantages can make up for that shortcoming for some use cases, and eventually there'll be enough momentum that one of those giant companies will pick it up. I can't see what other way there is to advance the state of the art, unless your position is going to be that C# is perfect and there's no point trying to do better. > I’m pretty sure that if in the future some programming language gonna become good enough to rule them all, that language will be much closer to modern C# than to modern Rust. Rust offloads a huge amount of complexity to developers What complexity is that? I'd argue that the trait system is a noticeable improvement over what's available in C#, and not having exceptions makes code significantly easier to understand. On linearity I could go either way - in theory it's more work for the developer, but borrow-checker friendly code styles tend to just be good coding style. Most of the time I write the same code I'd write in C#, Scala, or anything else, and it just work - and when it doesn't either the error messages have been clear and the fix has been easy, or it became clear that I was genuinely very confused about the problem and needed to rethink my whole approach. (But yeah actually GC is fine 100% of the time and Scala is already the one language to rule them all, people just haven't realised yet)

Const-me 6y ago
> What complexity is that? First and foremost ownership shenanigans. The complexity spill over the entire ecosystem. You can't write a fizz buzz without discovering the standard library has 2 types of strings because of that. > not having exceptions makes code significantly easier to understand Both error codes and exceptions have their place. Imagine a streaming parser of some XML/JSON/mpeg4/whatever. There's nothing you can possibly do in the parser to handle socket errors. Exceptions make parser's code more readable, essentially you pretend sockets never fail. > confused about the problem and needed to rethink my whole approach No amount of rethinking gonna help when you need a graph data structure in your code. Ownership shenanigans making graphs complicated in Rust, fundamentally so.
- lmm 6y ago
  > Imagine a streaming parser of some XML/JSON/mpeg4/whatever. There's nothing you can possibly do in the parser to handle socket errors. Exceptions make parser's code more readable, essentially you pretend sockets never fail. Disagree, because even if you can't handle errors in your code you have to do things like make sure resources are closed correctly. So you end up having to reason about exception safety, which is notoriously error-prone. If you have to have paths for propagating errors through your code, it's better to have them visible where you can reason about them, even if the actual handling has to take place at a different level. > No amount of rethinking gonna help when you need a graph data structure in your code. If you need a graph with cycles and you don't have a clear owner for the graph as a whole, sure. That's a pretty rare situation IME.
  - Const-me 6y ago
    > you have to do things like make sure resources are closed correctly. Not all code deals with resources. Streaming parsers normally don't. When you don't open/close any resources, manually propagating errors complicates code for no good reason. > a graph with cycles and you don't have a clear owner It's hard in Rust even for acyclic graphs with a clear owner, due to updates. Code that mutates the graph often needs to update multiple nodes at once, but Rust only supports a single writeable reference per object instance. All practical Rust implementations of graphs, trees and linked lists I saw use unsafe to workaround the fundamental language limitation. That's OK for linked lists because so simple and a standard library implementation is often enough. Graphs and trees however are very different based on use cases, can't implement just once and call it a day.