3 ms·

> All require runtimes. Which means they're not in the same class of language as C, C++, and Rust Right, which is why it makes no sense to say "no don't use C#

> All require runtimes. Which means they're not in the same class of language as C, C++, and Rust Right, which is why it makes no sense to say "no don't use C# for webdev!! Use Rust!" They're different classes of languages. If C# is good for that use case then use it. Also there are genuine benefits to having a runtime.

timschmidt 2y ago
> it makes no sense to say "no don't use C# for webdev!! Use Rust!" Well, first of all, I don't see anywhere where anyone said that. Perhaps in another thread? People did argue against the use of Rust for web dev, for which it's a perfectly reasonable choice among many. Second, I have an embedded HTTP server running on a microcontroller with 500kb of ram in my current project. Works great in Rust. Simply not possible in C#. > If [any language] is good for that use case then use it. Agreed. The best camera is the one in your pocket, and the best language is the one you know. > Also there are genuine benefits to having a runtime. Things which are commonly associated with runtimes - memory safety, automatic memory management, various type systems, high level language abstractions - are all genuinely useful. Folks in this thread seem to want to hold on to a categorization of languages which Rust breaks by virtue of providing features typically only found in languages with runtimes. What Rust shows is that those benefits can be a part of a well designed language, with or without a runtime. And not having a runtime is a hard requirement in areas like embedded, OS development, realtime, etc. There is typically a separation between languages you'd use for that sort of thing and languages you might use for web dev, but the reasons for that separation do not apply to Rust. Which is fun. Some people seem to be salty about it though, lol. One significant downside to having a runtime is that it significantly complicates the process of program verification. Making it much harder to do statically. Necessitating certain things happen at runtime like error handling and performance profiling. Rust mostly has what it needs to get that work done at compile time, which means the developer has an opportunity to fix it, before some user runs into it.
- consteval 2y ago
  > with or without a runtime This is the point - no, you actually DON'T get all the benefits of a runtime. C# famously, and extensively, used runtime code generation. Not possible in Rust, kind of possible in C++. > Necessitating certain things happen at runtime Not how it works. The language is still compiled. You can 100% implement a borrow checker for C#, there's nothing stopping anyone. It's just not what they want to do. For example, C++ and C are BOTH compiled languages. But C++ is able to verify the type of various operations at compile-time, but C has to wait until runtime. For example, C's qsort takes void pointers and then you cast and dereference them at runtime. In C++, this is physically baked into the type of function template std::sort. But they're both compiled languages with no runtime. But because C++ has a much more complete type system, it can do those things at compile-time while C cannot. Another example: while C# has polymorphized generics, it checks them at compile time! The generics are not monomorphized like C++ or Rust, which allows smaller linked libraries that you can load and use at runtime, which is not possible in C++ templates or Rust generics. The trade-off is then that generics can't be checked until runtime - but actually no. The C# compiler will go out of its way to check generics when it can and will fail if they don't meet the type constraints, just like C++ or Rust. Rust is very powerful, BUT: 1. It doesn't cover all the usecases of more powerful languages with rich runtimes like C# or Java 2. Using async rust, which is typically a requirement for webdev, requires a runtime anyway.
  - neonsunset 2y ago
    > Another example: while C# has polymorphized generics, it checks them at compile time! The generics are not monomorphized like C++ or Rust, which allows smaller linked libraries that you can load and use at runtime, which is not possible in C++ templates or Rust generics. The trade-off is then that generics can't be checked until runtime - but actually no. The C# compiler will go out of its way to check generics when it can and will fail if they don't meet the type constraints, just like C++ or Rust. Generics are not monomorphized at bytecode level, but whenever generic argument is a struct, the methods and types that have it are monomorphized at the stage of compiling to machine code, be it with JIT or ILC. This is identical to Rust, and is why C# has "zero-cost" abstractions. Method bodies and types for class-type generic arguments are indeed shared however. Dispatch on generic constraints is still quite efficient in that case, even if no longer zero-cost (unless the compiler is able to see the exact type and inline such calls, or emit a guarded devirtualized fast-path when compiled by JIT, or prove that only few types implement a particular interface or subclass a specific parent when compiled by NativeAOT).
deleted 2y ago
[deleted]

timschmidt 2y ago

> it makes no sense to say "no don't use C# for webdev!! Use Rust!" Well, first of all, I don't see anywhere where anyone said that. Perhaps in another thread? People did argue against the use of Rust for web dev, for which it's a perfectly reasonable choice among many. Second, I have an embedded HTTP server running on a microcontroller with 500kb of ram in my current project. Works great in Rust. Simply not possible in C#. > If [any language] is good for that use case then use it. Agreed. The best camera is the one in your pocket, and the best language is the one you know. > Also there are genuine benefits to having a runtime. Things which are commonly associated with runtimes - memory safety, automatic memory management, various type systems, high level language abstractions - are all genuinely useful. Folks in this thread seem to want to hold on to a categorization of languages which Rust breaks by virtue of providing features typically only found in languages with runtimes. What Rust shows is that those benefits can be a part of a well designed language, with or without a runtime. And not having a runtime is a hard requirement in areas like embedded, OS development, realtime, etc. There is typically a separation between languages you'd use for that sort of thing and languages you might use for web dev, but the reasons for that separation do not apply to Rust. Which is fun. Some people seem to be salty about it though, lol. One significant downside to having a runtime is that it significantly complicates the process of program verification. Making it much harder to do statically. Necessitating certain things happen at runtime like error handling and performance profiling. Rust mostly has what it needs to get that work done at compile time, which means the developer has an opportunity to fix it, before some user runs into it.

consteval 2y ago
> with or without a runtime This is the point - no, you actually DON'T get all the benefits of a runtime. C# famously, and extensively, used runtime code generation. Not possible in Rust, kind of possible in C++. > Necessitating certain things happen at runtime Not how it works. The language is still compiled. You can 100% implement a borrow checker for C#, there's nothing stopping anyone. It's just not what they want to do. For example, C++ and C are BOTH compiled languages. But C++ is able to verify the type of various operations at compile-time, but C has to wait until runtime. For example, C's qsort takes void pointers and then you cast and dereference them at runtime. In C++, this is physically baked into the type of function template std::sort. But they're both compiled languages with no runtime. But because C++ has a much more complete type system, it can do those things at compile-time while C cannot. Another example: while C# has polymorphized generics, it checks them at compile time! The generics are not monomorphized like C++ or Rust, which allows smaller linked libraries that you can load and use at runtime, which is not possible in C++ templates or Rust generics. The trade-off is then that generics can't be checked until runtime - but actually no. The C# compiler will go out of its way to check generics when it can and will fail if they don't meet the type constraints, just like C++ or Rust. Rust is very powerful, BUT: 1. It doesn't cover all the usecases of more powerful languages with rich runtimes like C# or Java 2. Using async rust, which is typically a requirement for webdev, requires a runtime anyway.
- neonsunset 2y ago
  > Another example: while C# has polymorphized generics, it checks them at compile time! The generics are not monomorphized like C++ or Rust, which allows smaller linked libraries that you can load and use at runtime, which is not possible in C++ templates or Rust generics. The trade-off is then that generics can't be checked until runtime - but actually no. The C# compiler will go out of its way to check generics when it can and will fail if they don't meet the type constraints, just like C++ or Rust. Generics are not monomorphized at bytecode level, but whenever generic argument is a struct, the methods and types that have it are monomorphized at the stage of compiling to machine code, be it with JIT or ILC. This is identical to Rust, and is why C# has "zero-cost" abstractions. Method bodies and types for class-type generic arguments are indeed shared however. Dispatch on generic constraints is still quite efficient in that case, even if no longer zero-cost (unless the compiler is able to see the exact type and inline such calls, or emit a guarded devirtualized fast-path when compiled by JIT, or prove that only few types implement a particular interface or subclass a specific parent when compiled by NativeAOT).

deleted 2y ago

[deleted]