5 ms·

C# is fast and .NET core is cross-platform. It's good for games, web, and mobile development. F# is a great functional programming language. There are fun tools

by icey 5y ago

C# is fast and .NET core is cross-platform. It's good for games, web, and mobile development. F# is a great functional programming language. There are fun tools like SignalR (easy websockets), Blazor (write C# and run it in the browser through WASM), and LINQ (built right into the language and allows you to query objects like a database). Toplevel programs should make it easier to experiment with C# if you're interested. We also have first-class support for C# commands in https://ab.bot https://ab.bot if you just want to play around with the language and make a fun Slack bot or something, although it might take us a week or so to get move up to .NET 6.

kbd 5y ago
> and LINQ Shudders at memories of coworkers writing giant, ridiculously inefficient LINQ queries without understanding how it's actually using the database and what it's doing server-side > Toplevel programs should make it easier to experiment with C# if you're interested. Definitely interested in that small feature :) If I had extra time I'd like to see what it takes to brew install dotnet and write a simple CLI program. Can .NET deploy a static binary nowadays?
- tfigment 5y ago
  True of nearly all ORMs really. LINQ on objects basically makes C# a very nice functional language. Dapper is arguably better for database but then use LINQ in those results is very nice.
  - mumblemumble 5y ago
    I almost wish they hand't wrapped IQueryable and IEnumerable under the same branding. I get that there's a lot of overlap at the interface level, but, in terms of what they're doing under the hood and the effect on how you use them, they're really quite very different.
  - kbd 5y ago
    > True of nearly all ORMs really. I disagree in a respect. I think with an ORM it's clear when you're hitting the database, though it makes it easy to write loops over (related) rows ("n+1 problem"). I think with LINQ using the same syntax/expressions across local and remote operations it can be more blurred what's happening.
- sbelskie 5y ago
  > Can .NET deploy a static binary nowadays? You can bundle everything in a single file but that file contains the runtime, so even small Hello World apps are 50MB+ last I checked, though there have been some improvements recently with trimming and AOT is hopefully coming next year with .NET 7.
  - kbd 5y ago
    Very cool, thanks for answering. Yeah I understand they'd have to bundle the runtime so that makes sense. Glad to know they're working on improving that use case as well.
    - wvenable 5y ago
      They're really working on reducing the compiled (app + framework) size in order to make the WASM target in browsers more viable for Blazor.
  - ripley12 5y ago
    Yeah, starts closer to 12MB for a trimmed console app in .NET 6. It works really well (I've been distributing one for a few months now).
- int_19h 5y ago
  LINQ is best when used on in-memory object graphs, partly for the reasons you brought up, and partly because then you're not dealing with weird limitations or deviations from how functions normally work etc. For in-memory queries, it's basically just a very advanced form of sequence comprehensions. (I also suspect that the vast majority of LINQ code in the wild is of that variety, rather than Entity Framework etc.)
- jeswin 5y ago
  > Can .NET deploy a static binary nowadays? You can, as sbelskie mentioned below. In .Net 6, it's available as a Preview [1]. But it's going to ship with the main framework in 7.0 [2]. The preview works quite well. You can build self-contained, smaller executables, and shared libraries callable from say, C code. [1]: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/compiling.md https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/... [2]: https://github.com/dotnet/runtime/issues/61231 https://github.com/dotnet/runtime/issues/61231

by icey 5y ago

kbd 5y ago

> and LINQ Shudders at memories of coworkers writing giant, ridiculously inefficient LINQ queries without understanding how it's actually using the database and what it's doing server-side > Toplevel programs should make it easier to experiment with C# if you're interested. Definitely interested in that small feature :) If I had extra time I'd like to see what it takes to brew install dotnet and write a simple CLI program. Can .NET deploy a static binary nowadays?

tfigment 5y ago
True of nearly all ORMs really. LINQ on objects basically makes C# a very nice functional language. Dapper is arguably better for database but then use LINQ in those results is very nice.
- mumblemumble 5y ago
  I almost wish they hand't wrapped IQueryable and IEnumerable under the same branding. I get that there's a lot of overlap at the interface level, but, in terms of what they're doing under the hood and the effect on how you use them, they're really quite very different.
- kbd 5y ago
  > True of nearly all ORMs really. I disagree in a respect. I think with an ORM it's clear when you're hitting the database, though it makes it easy to write loops over (related) rows ("n+1 problem"). I think with LINQ using the same syntax/expressions across local and remote operations it can be more blurred what's happening.
sbelskie 5y ago
> Can .NET deploy a static binary nowadays? You can bundle everything in a single file but that file contains the runtime, so even small Hello World apps are 50MB+ last I checked, though there have been some improvements recently with trimming and AOT is hopefully coming next year with .NET 7.
- kbd 5y ago
  Very cool, thanks for answering. Yeah I understand they'd have to bundle the runtime so that makes sense. Glad to know they're working on improving that use case as well.
  - wvenable 5y ago
    They're really working on reducing the compiled (app + framework) size in order to make the WASM target in browsers more viable for Blazor.
- ripley12 5y ago
  Yeah, starts closer to 12MB for a trimmed console app in .NET 6. It works really well (I've been distributing one for a few months now).
int_19h 5y ago
LINQ is best when used on in-memory object graphs, partly for the reasons you brought up, and partly because then you're not dealing with weird limitations or deviations from how functions normally work etc. For in-memory queries, it's basically just a very advanced form of sequence comprehensions. (I also suspect that the vast majority of LINQ code in the wild is of that variety, rather than Entity Framework etc.)
jeswin 5y ago
> Can .NET deploy a static binary nowadays? You can, as sbelskie mentioned below. In .Net 6, it's available as a Preview [1]. But it's going to ship with the main framework in 7.0 [2]. The preview works quite well. You can build self-contained, smaller executables, and shared libraries callable from say, C code. [1]: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/compiling.md https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/... [2]: https://github.com/dotnet/runtime/issues/61231 https://github.com/dotnet/runtime/issues/61231