9 ms·

Beware, the rustification has broken thru .net defenses :) Not sure if I ever find use for Rust in .net runtime (C# has more or less same capabilities), but con

• CharlieDigital 3y ago
  C# as a language seems supremely underappreciated/misunderstood. It seems like it should have higher adoption given the performance boost over JS on Node while being syntactically similar to TypeScript (not hard to adopt for teams already familiar with JS/TS). Combined with pretty good tooling these days and DX (hot reload is a thing), I'm always surprised by its seemingly lackluster reception.
  • yungporko 3y ago
    C# really is a brilliant language, but all of the awful microsoft bullshit surrounding it ruins its image.
    • psd1 3y ago
      Do you mean the .Net Foundation brouhaha a year or two ago around code ownership? Or Visual Studio, the product? Or simply that some people will never forgive Microsoft for embrace-extend-extinguish and as a result won't ever give any tech a chance of it originated from Microsoft?
    • CharlieDigital 3y ago
      In my 20 some years of using .NET and C#, I don't think I've ever run into a case where I felt "this is some Microsoft bullshit". It's continuously gotten better, but I feel that many folks still have an image of C# and .NET from back in 2003 rather than 2023.
      • slikrick 3y ago
        if you've only used it on windows then you have constantly been running into the case of only using it for Microsoft bullshit...
        • CharlieDigital 3y ago
          I've been using it exclusively on an M1 Mac for the last 2+ years. I was just at a startup where the entire team was deploying into T4 Arm instances in AWS. Two developers started on Windows machines, but at the end, every developer was on a Mac. I have some workloads that I'm developing on my M1 Mac that I'm containerizing and pushing into an x64 Linux runtime environment in Google Cloud. I guess this is my point: a lot of misunderstanding and misconception about the state of C# and .NET.
        • paddim8 3y ago
          What do you mean? It has great support for other platforms. I've been using it on Linux for as long as .NET Core has existed and it has always felt really natural and there are as much documentation for Linux as for Windows with the things I've been doing
      • yungporko 3y ago
        in my 10 years of using .NET and C# i encounter microsoft bullshit most days, so i would bet money that you run into those cases all the time but just got used to it lol
    • ComputerGuru 3y ago
      I’ve been using C# since 2001, before C# 2.0 and its generics rewrite and when J# was a promising star in Microsoft’s eye. There is no “Microsoft bullshit” surrounding the language any more. Microsoft runs it in production on Linux and the language (and runtime) has been transformed. (If only we could first-class FreeBSD support…)
      • yungporko 3y ago
        msbuild, entity framework, msal, visual studio and all the jank and bloat that comes with it, all microsoft bullshit which exists right now.
        • CharlieDigital 3y ago
          I don't get it. - EF Core works great. We connected it to RDS Postgres in AWS with container instances running on T4g ARM instances. - Our pipeline used the `dotnet` CLI to do all the builds on our local M1 MacBook Pros and in GitHub Actions on Linux runners. Want to build a .NET codebase? `dotnet build` from the CLI. Want to run it? `dotnet run`. Want to watch for file changes and hot-reload? `dotnet watch`. .NET is really, really streamlined right now. Better than Node at the moment (as a dev that works fullstack and has workloads on .NET and Node). - Our team used a mix of VS Code and JetBrains Rider. Two devs started on VS Mac, but eventually we all ended up using VSC or Rider on Mac. - Bloat is pretty minimal; really easy to build a console app or a web API that more or less looks like an Express web app. Here's a 7 minute video demonstrating building a .NET web API on an M1 Mac and then pushing it into an x64 Alpine Linux container in Google Cloud Run: https://youtu.be/GlnEm7JyvyY https://youtu.be/GlnEm7JyvyY
  • wofo 3y ago
    Here in The Netherlands I've seen it extensively used (and I'm using it myself in some projects, though nowadays the bulk of my work is in Rust)
    • CharlieDigital 3y ago
      I was working at a YC startup which was re-writing a portion of their backend to address some scalability and performance issues. The team was already familiar with JS and TypeScript as the initial implementation was Node. I suggested C# because of the similarity to TS syntactically while being multi-threaded and more performant for the use case but was amazed at the backlash. It's interesting to me that many teams that are already comfortable working full stack with TS reach for Go or Rust instead of C#. I can understand Rust if a team is doing systems level programming, but C# is an easier lift than Go (IMO) for teams building APIs and apps who are already versed in TS because the paradigms are very similar (async/await, try-catch-finally, generics, inheritance, tuples, deconstruction, anonymous types, general syntax, etc.)
      • wofo 3y ago
        Yeah, I'm a huge fan of C# for web stuff. I'd take it over Rust any day, unless there are strong reasons to want a systems language.
  • stevefan1999 3y ago
    Just like the Windows kernel is actually pretty good, as most of the kernel architecture and design decision predates Linux kernel by 20 years, which Linux kernel slowly incorporated in a form or another progressively. Noticeable things such as employing hybrid monolithic-microkernel design/kernel modules/SMP/cross-platform capability existed in Windows kernel long before Linux is mainstream. An honorable mention would be the Job Object since Windows 2000, and it is the nephew of Cgroups that is a key component in the Linux Container scene. NTFS is also one of the most successful B-tree based transactional filesystem that has many hidden gems behind. But Windows userspace things and most infamously Microsoft Office, and Microsoft's hostile and manipulative approach towards end-users makes the whole Windows thing very shitty, while I believe Linux is the other way round, the whole ecosystem is built around free and openness. In the end the tech for building the foundation of the Windows is great but the execution by the upper management is disastrous. For C#, this is the first language that provided the now ubiquitous async/await asynchronous programming syntactic sugar to the masses. Before that, we have to use something called Begin/End pattern called APM (Asynchronous Programming Model) which is already foreseeing a CPS (Continuation-passing style) based async programming. The async/await pattern, or the state machine + futures approach quickly spread to ECMAScript, Rust and recently C++20. Don't get me started with LINQ/PLINQ, expression tree (which is a cousin of LISP macro) and extension methods (Rust and D people should know it as mixin/traits and UFCS), which is bringing a life-changing SQL like data operation pattern, which not only runs on SQL (LINQ to SQL) but also for daily life programming. I'm very confident that LINQ predates and heavily inspired Java Stream and Rust iterator design, with Java Stream being a half-assed copy of LINQ and Rust a saner one. Not only that, but C# lambda is also far better than Java where you can only use final variables in Java lambda, which is based on anonymous class generation (you will understand it once you turn on a Java decompiler), while C# lambda is implemented using something called "delegate", which is an analogy of "function pointer" to C/C++ and is even interoperable as a native code thunk with API marshalling. So, you can indeed store C# delegates into native function pointers and callback to C# from C++ later. You also have first of its own FFI in C# with DllImport, and with the magic of JIT almost all C/C++/native method can be imported efficiently and directly without so much preprocessing unlike JNI/JNA in Java. No need to manage Java state and stuff in C++, just figure out the right ABI and structs, but those are up to the user to implement which is still closed under C#. C# also have the right kind of reified generic that does take types into consideration (hence reified) unlike Java which does Type Erasure instead, and eventually making the "generic" type into nothing but a glorified Object and losing a lot of optimizations opportunity due to this loss of information. Java only recently started to work on value type with Project Valhalla. C# already has it from the beginning. But, Microsoft is so shitty that it binds .NET Framework to integrate with Windows heavily. They want you to stick with WPF/WCF, IIS, SQL Server and ASP.NET, which is cool in the beginning but barely evolves and is missing what others have in the long run. Plus, the hostile attitude of Microsoft towards open competitor such as Linux from the early days (remember that Microsoft once called Linux "cancer" but now tried to fully embrace it, while I'm not sure when will Microsoft extend and extinguish Linux), with a big contrast to Sun's Java (until the acquisition from Oracle, which today turned to become a hostile and threatening old Microsoft monster). As such, the development and ecosystem of .NET and C# in extension, is often being laughed at as Microsoft shut-in and the developers as Microsoft fanboys. The trend is even more pessimistic when Android adoption exploded, which uses Java as the foundation for software development. So this is why C# development staggered since 2014. There is no competition between Java and C# anymore, because Java already killed it. Barely anyone uses .NET at that point on. .NET missed a lot of growing opportunities especially in China which is being ridiculed to this day despite many improvements over the years, although this is more of a political choice over technical choice since there are tons of Java developers everywhere in China, most of them are often hostile to C# developers because they are taught not to embrace Microsoft. While Mono is an exception, and it once exploded with Unity Engine (but now replaced by IL2CPP), it is still a pretty niche market (well, .NET itself is already being marginalized as a niche), and I assert they must have been in the brink of getting sued by Microsoft a couple of times in the past 20 years by copying some key components of the .NET Framework. Still, the relative success of Mono in the cross-platform market is a good attempt into making Microsoft rethink their hostile strategy and is a key catalyst to gradually make .NET open. So, Microsoft is essentially burying diamonds and gold and jewels upon piles and piles of shit. They totally have the right minds and the capability to pull off the most stunning, impressive and revolutionary tech, but there are simply too many idiotic managers that does little to no coding, with a heavier side on greedy marketing just for the quick bucks, to cockblock and kill off those innovative projects, much like the Google today.
  • ComputerGuru 3y ago
    The C# tooling is second to none. (I keep hearing rumors of native Visual Studio support for rust, but they never seem to pan out.)
  • gwbas1c 3y ago
    > while being syntactically similar to TypeScript The guy who invented C# went on to invent TypeScript. I've been working with C# for over 20 years. The big problem with C# in the early days was the ecosystem: an awesome language, awesome IDE, but limited libraries and bloated frameworks. .Net Core fixed a lot of this: ASP Core works more like Express, where routing is declarative, and has no surprises. In contrast, the original ASP for .Net used reflection to infer routes at runtime, which was extremely fragile. The way that NuGet works now is more like cargo / npm; but before that package management was either all DIY or unpredictable. IE: Until .Net Core, you could argue that C# was a better language, but end up getting trapped in the shortcomings of the ecosystem. Now that the ecosystem is on par with Rust / Node, it's much better. I do think there needs to be a way to smooth over the difference between sync and async APIs. Far too often the difference between an async and sync method is just copy/paste. There needs to be a way for async/sync to just JIT out to call either the sync or async method of the stream/socket/lowest level API.
    • CharlieDigital 3y ago
      Because of that lineage and syntactical similarity, I'm always surprised it's not more widely adopted by startups that need to extend beyond Node. I've worked at one YC startup and interviewed with others. C# seems like the natural step after TS. But several were more interested in Go and Rust. Strange to me when C# seems more logical.
      • gwbas1c 3y ago
        As much as I like C#, every time I'm on the job market, I end up taking a job in C#. Rust's biggest advantage over C# is that it's framework-free. IE, you compile a working executable; nothing more is required. What's harder to understand is: Will I be more productive using Rust compared to C#? (After dealing with the learning curve.) Will my code be "faster enough" to lower the cost of operations? (IE, a cluster of 5 servers instead of 15?)
• colejohnson66 3y ago
  I really love C#, but one thing I wish it had (that Rust does) is move semantics. In C#, if someone passes your function (such as a constructor) an array, you have no guarantee the caller won’t modify it underneath you. In Rust terms, you would have a mutable reference, but the caller also does. Sometimes this is desired, and would be usable in Rust with a Cell, but other times it’s not. This can lead to defensive copying of arrays by the callee. If I could annotate a parameter with some kind of “move” keyword that would prevent the caller from using it again, that would be great. “Frozen collections” and ImmutableArray<T> can solve this issue, but the latter is essentially just a defensive copy of the array, but in a special type. I'm not holding my breath that such a thing would ever be implemented; Analyzers will probably be the best we get.
  • CharlieDigital 3y ago
    Wouldn't this just be ImmutableArray or ReadOnlyCollection? > “Frozen collections” and ImmutableArray<T> can solve this issue, but the latter is essentially just a defensive copy of the array, but in a special type OK. Or just declare your parameter as IEnumerable<>? This has the effect of restricting the operations on the incoming collection in the same way.
    • colejohnson66 3y ago
      Obviously, if this is a processing function that iterates over the array and forgets about it, IEnumerable<T> or IList<T> (IReadOnlyList<T> to communicate intent) would be the better option. My thoughts involved constructors. In those, sure, I could take IEnumerable<T> or whatever else there is, but if I want to store an array (or list) as a field in my class, I'd have to make a copy with ToArray() (and friends). Being able to "move" an array from the caller into the constructor (callee) would be nice. ReadOnlyCollection<T> isn't actually read only, but just a wrapper around an array/list. IReadOnlyList<T> also isn't read only, but just restricts me from editing it. I can't edit the parameters, but the caller possibly could, and that's my issue.
      • CharlieDigital 3y ago
• ComputerGuru 3y ago
  I’m apparently one of the few that use rust and C# as my language duo of choice; our company has gone all in on both. I think the more common combos are golang/rust, js/rust, or python/rust. But proper support for discriminated unions (and perhaps something better than the emasculated match blocks known as switch expressions) cannot come soon enough for C# to enter the big leagues.
  • gorkempacaci 3y ago
    What’s this company, if we may ask?
    • ComputerGuru 3y ago
      NeoSmart Technologies. Our GUI and web stuff is C# and we’ve been migrating our low-level C and C++ code to rust (no_std rust for most of the C stuff). Some of our existing C/C++ stuff is extremely low level (think bootloaders, virtualization tech, etc) but also cross-platform and we’ve found rust to offer great ergonomics (not to mention safety) without an impedance mismatch under those constraints. We’re also using rust for cli utilities and non-client-facing backend server stuff.
      • gorkempacaci 3y ago
        Thank you. You make interesting stuff.
        • ComputerGuru 3y ago
          Thanks! None of it is currently particularly in vogue, but it certainly satisfies the research and chasing rabbits^W gremlins down tunnels itches.
  • lostmsu 3y ago
    I guess hi )