20 ms·

Why Tracebit is written in C#

• halfcat 2y ago
  C# is solid. It’s not necessarily the best at anything (is it?), but its floor is like a 3 out of 4 across the board. I remember making a big spreadsheet of languages and a bunch of potential areas of use. Building desktop apps, mobile apps, games, concurrency, performance, cloud native, web apps, data pipelines, and machine learning. C# is 3 out of 4 on all of those, except maybe 4/4 on games with Unity, and being cloud native with Azure, C# gives you a bunch of stuff automatically especially around observability.
  • Atotalnoob 2y ago
    C# has changed a ton in the last few years, it’s definitely 4/4 for me…
    • CharlieDigital 2y ago
      It's getting closer and closer to TypeScript.
      • yodon 2y ago
        You presumably are aware that C# and TypeScript share the same original language designer
        • CharlieDigital 2y ago
          Yes; GOAT. What's interesting is whereas a very large community has embraced TS, C# feels like it hasn't gotten as much love despite being so similar at a language construct level (async, exceptions, generics, etc.)
      • Atotalnoob 2y ago
        They were made by the same dude, so it makes sense they are similar.
      • pier25 2y ago
        Probably the other way around...
        • CharlieDigital 2y ago
          It's bi-directional. In recent years, C# has gained destructuring, collection initializers, tuples, and a few other niceties. JS/TS are missing expression matching that C# gained, but there's a proposal for it for JS. C# is missing discriminated unions, but there's a proposal in process for it.
  • caspper69 2y ago
    I am a huge C# advocate, and with the AOT stuff since .NET 7, they are really working overtime to add features for safe low-level operations. Some of the niceties over the last several versions include immutable record types, stack allocated structs (ref structs), lambdas (and a host of enhancements thereof since), async/await (of course), generic math ops, platform intrinsics, pattern matching, AOT, nullable types, robust generics, reflection, dynamic types, etc. The big thing I expect next is algebraic data types. The language has really grown by leaps and bounds, but it doesn't ever feel overwhelming, and it has really kept its verbosity to a minimum without turning into a soup of hieroglyphics. That being said, I have found the Android/iOS solutions to be underwhelming. I understand the iOS side a bit, but I thought Android would be better. That's not to say you can't make great applications using C# on these platforms, just that it requires more effort. I'm also not a huge fan of ASP.Net. I've never really cared for it, and I think that stems from a project I had early in my career duct-taping together another developer's classic ASP applicat^HHH monstrosity and mucking about with IIS and FoxPro (!!). I know it's not classic ASP, but once bitten, lol. I will say that it is modern and performant, but very rigid. I'd defer to others' opinions here because I have mostly avoided it. But in general, the tooling is great, and I don't encounter much that ties you to a Windows box anymore. I know there are some differences in platform support, but most of the rough edges were handled in the early days of .NET Core 2 & 3. Now that we're way past that (the "traditional" .NET merged with .NET Core in a combined version 5 release). Now that it's on version 9, the language features and low-level hits keep coming. I can, today, write code that is 99% of what you can get from C++ (and in some edge cases can exceed it), compiled to native code, that will run on Windows & Linux (x64 & arm64), BSD & MacOS without too much trouble. And as a fellow HNer pointed out the other day on an unrelated thread, the native interop is painless. You can load .dll, .so, .dylib files with ease. No frankenstein FFI (ala Go or Java). The language is safe. GC can be avoided (or controlled), and it offers raw pointers, manual memory manipulation with spans, and more low-level features through the unsafe subset of functions. I know people like to say this started as a rip-off of Java, and there is some truth to that, but I have too much respect for Anders to believe he set out to rip off Java part and parcel. There was a method to his madness, and from my perspective, C# has always been a step ahead in programmer ergonomics (but definitely not performance). Maybe that's due to the sheer intertia of the Java ecosystem, or to Sun and then Oracle being more conservative, I don't know. Hell, it probably had more to do with Microsoft's reputation. I value programmer ergonomics and tooling, almost above all else, and I am a happy camper. You can write C# from several different angles as you see fit, and in most cases it checks all the boxes for a large subset of projects.
• unsignedint 2y ago
  One thing I appreciate about C# and .NET is how well they resist codebase rot. In some other languages, I often encounter situations where the development environment needs to be completely recreated—sometimes due to an updated interpreter version or other breaking changes. If you've been away from the codebase for a while, chances are you'll need to make modifications just to get it running in a more recent environment. With .NET, this issue is much less pronounced. While occasional adjustments are necessary, the environment is largely self-contained, minimizing the overhead required to get things running. As long as the .NET SDK is installed, running dotnet restore is usually all it takes—even when moving the codebase to an entirely new machine. Some third-party libraries evolve more rapidly than others, but the core .NET libraries remain remarkably stable. More often than not, you can transition between major versions without needing to modify any code. If I were starting a long-term project that required ongoing maintenance, C# would be my top choice. For quick scripting needs, I’d lean toward Python or PowerShell. In fact, PowerShell itself is another reason I appreciate .NET—it shares many concepts, and knowing .NET makes it easier to understand PowerShell. Plus, since PowerShell can directly leverage .NET libraries, it offers powerful scripting capabilities. I was thrilled when PowerShell became cross-platform, much like .NET itself.
  • whoknowsidont 2y ago
    >With .NET, this issue is much less pronounced. This is because Windows comes with some form of .NET, but also other programs end up needing to install multiple versions of the .NET runtime. Eventually, you just have them on your machine. It's the equivalent to installing every version of Python and just letting the problem sort itself out. It's not different than other tech-stacks, you're just eating the costs up front instead of running into them in a more obvious manner. .NET (in its entirety) has lots of breaking changes that won't work from one version to another. More recently MS has been better about documenting these, especially as .NET's footprint increases inside outside of the control of MS (non-Windows environments): https://learn.microsoft.com/en-us/dotnet/core/compatibility/breaking-changes https://learn.microsoft.com/en-us/dotnet/core/compatibility/... >In fact, PowerShell itself is another reason I appreciate .NET it shares many concepts PowerShell is built on .NET (in whatever form .NET Framework and .NET/core) lol. It doesn't "share" anything, it _IS_ shell for .NET.
• codr7 2y ago
  Makes sense, but Java's mostly portable library eco-system and its maturity would make a very strong contender to me.
  • GiorgioG 2y ago
    As opposed to .NET’s mostly portable library ecosystem?
    • codr7 2y ago
      Definitely not as mature and portable from my experience.
      • metaltyphoon 2y ago
        Well… the moment you have to do FFI in Java is when you give up. It’s straight up the worst I’ve seen from all higher level languages. I rather do CGO than use JNI. Its actually less bad when using Rust but still bad.
        • za3faran 2y ago
          This is supposed to replace JNI from what I gather: https://openjdk.org/jeps/442 https://openjdk.org/jeps/442
        • vips7L 2y ago
          Java is my go to for everything. In my entire career I’ve never had to use FFI.
          • metaltyphoon 2y ago
            Interesting, from 3 different jobs, all of them needed FFI. The first one was using C#. The second was Swift and Java (android). The current one is Java, NodeJS, C#, Python, Go. This tends to happen when you want to write common shared libraries that are business critical and want one implementation only or when the library exist but in another language.
• sophiacamille 2y ago
  I have tried quite a few languages over the years. C# is my favourite. I don't really know why, it just feels like a cosy, warm jumper.
  • bartwr 2y ago
    I share the sentiment. I haven’t used it in a while (at work use different languages and in the last few years my personal coding is only Python script/Jupyter notebook bite-sized), but anytime I hop into it, it immediately "clicks" and gives a comfortable feeling, despite changing over years. A perfect language for medium sized relatively clean and mature personal or small team projects. Frictionless, pleasant, not thinking too much how to express things (and still managing to write them reasonably idiomatic), tends to support clean encapsulated code, quite rich environment/libraries, great tools (debuggers, profilers), safe, relatively fast, not many foot guns, zero build setup, on small project zero build times, trivial to create good functional simple UI, can get fancy dynamic with reflection when I need "magic". Basically not many pain points that would make me rage quit and almost everything I'd want is simple to achieve.
  • Akronymus 2y ago
    C# is my second favourite language, despite it being OOP first. My personal fav is F#.
    • taberiand 2y ago
      Each new C# release seems to borrow yet another F# feature, to its benefit. I prefer F# too, but at least I can convince the team to use C# - F# seems to be a bit too intimidating (in its awesomeness, I assume) for most devs to learn.
  • bitwize 2y ago
    There's no programming-language cozy like Lisp cozy, but I can see myself working quite happily in C#.
  • alkonaut 2y ago
    Same. I think it’s because it’s easy to read and write, and its worst design warts are at least not ridiculous like they are in say JS or Go, where there are massive cons to weigh against the pros. C# just feels like it’s pretty decent across the board instead.
• spicyusername 2y ago
  I recently waded into using C# to tinker with video game development using MonoGame, and I have been so surprised by how nice of a language it is to use. With the exception of maybe Tagged Unions, it has all of the language features I could want, and the syntax is very clean and easy to read.
  • runevault 2y ago
    And they're working on Unions, although last I heard they won't make it into dotnet 10/c# whatever version is coming with it.
    • S04dKHzrKT 2y ago
      Here's the language proposal for those that are interested. https://github.com/dotnet/csharplang/issues/8928 https://github.com/dotnet/csharplang/issues/8928
• lordofgibbons 2y ago
  How does it compare with Kotlin for backend development, which inherits all of the JVM ecosystem?
  • caspper69 2y ago
    There's a lot of banter as to which JIT environment is more performant. As a big C# proponent, my gut tells me the JVM probably has the edge here, but it's not a clean sweep. The CLR has areas where it excels. I would also freely admit that the Java ecosystem is far larger and more mature. The NuGet ecosystem is no slouch, however. But if I were a gambling man, I would bet that AOT compilation will become much more widespread in the .NET ecosystem while Oracle will ensure that you have to pay the piper for GraalVM to do anything interesting. Call it a hunch.
    • lordofgibbons 2y ago
      Thanks for the response. I mean from a productivity point of view when building real-world applications. For example, in Go, the development productivity is great, but I'm not so sure about feature development velocity. There are a ton of HTTP libraries, but it's a barren wasteland when it comes to Auth solutions and you have to rely on a separate service which unnecessarily complicates the infrastructure. Need to quickly put together an application that supports enterprise OAuth? tough luck
      • caspper69 2y ago
        Asp.Net supports both internal & external auth(n|z) providers. I have to admit that I haven't done much with the interweb side. Truth be told, the few times I've used Asp.Net, I used KeyCloak as the authentication provider, and that's Java-based, lol. That being said (and damn you for making me link to ms docs yet another time today), there is a built in provider, but my recollection is it did not support OAuth2 or JWT: https://learn.microsoft.com/en-us/aspnet/core/security/?view=aspnetcore-9.0 https://learn.microsoft.com/en-us/aspnet/core/security/?view... It may not suit your needs, but maybe that high-level doc can help you drill down quickly and not waste too much time on it. I will say that I do always find it amazing how large sites can be sucessfully operated without too much fuss on the platform. Stack Overflow was notorious for being a very high traffic site that ran on a small cluster of machines and was all done in Asp.Net (might have been the old Windows framework, however). I would like to add that I've been working with Entity Framework (EFCore) for the past year, and I've found it to provide velocity on that front. Never was a big ORM fan, but I can definitely see the use cases now.
• whoknowsidont 2y ago
  I'm kind of shocked that one of the qualifiers for choosing a tech-stack wasn't security, on a product that's specifically in the cyber-sec domain? They should have gone with Rust if they wanted to choose something new. C would have been respectable. >Some fairly trivial CSS build steps using node have more dependencies than our entire C# product! I don't know if I would really trust anything else written here. This is a security-focused product. Surely they understand that explicit, external dependencies are in fact safer than internal, implicit or "quiet" dependencies that make it hard to pinpoint attack vectors. It's really trivial to say, set up "canaries" around the former dependencies vs. the latter. Red team 101. Also .NET's runtime is _incredibly_ transparent, which is part of the reason why it's "reflection" capabilities are so powerful. And this can often be a great thing for developers, but I don't know about a security product that's supposed to be acting as a defense line. This is why even most obfuscation programs struggle with .NET because ultimately you can't really obfuscate much (pass some elementary things that have been obsolete since 2009 at least). .NET programs can also "mutate" dramatically with no hope of detection except by outside sources that are constantly checking for the integrity of known programs. And I'm not talking about "compile-after-delivery" vectors either. For example it's pretty well known in some circles that the CLR's dynamic assembly initialization and reflection capabilities allow you to even bypass AMSI. For _security-focused_ products and minimizing the blast radius on endpoints/systems, .NET (like other similar tech-stacks) really should be a no-go. >Honestly, we’re not doing real-time/systems/embedded programming; we can afford a GC pause. God this really hurts to read. You guys are really worried about the wrong thing(s).
  • CharlieDigital 2y ago
    > I'm kind of shocked that one of the qualifiers for choosing a tech-stack wasn't security, on a product that's specifically in the cyber-sec domain? This is a bad take. GitHub's State of the Octoverse 2020 security report is a good read[0]. The nuget ecosystem has among the lowest package advisories, the percentage of active repos receiving Dependabot alerts, and .NET packages overall have very low numbers of direct dependencies (reducing the surface area for vulnerabilities in the supply chain). A big benefit of the large first party ecosystem and broad base class library is that there are large teams of paid, professional engineers whose job is to actually track CVEs and patch vulnerabilities in .NET and C# as well as Microsoft's first party libraries. If anything, I'd say .NET/C# are probably one of the better choices if you plan to build in a regulated or secure context because of the large first-party libraries and active monitoring and patching of CVEs by Microsoft engineers. [0] https://octoverse.github.com/2020/ https://octoverse.github.com/2020/ (download the full PDFs)
• GiorgioG 2y ago
  Every time I futz around with another language I go back to C# for backend work. Part of it is likely due to familiarity (I’ve been using it since 2002). I wish MS would put some additional resources into F#.
  • ngrilly 2y ago
    What do you miss in F#?
    • GiorgioG 2y ago
      Microsoft has never taken it seriously, often releasing Visual Studio with broken F# support. It's fine for something you want to tinker with (like say Elm), but not something that's easy to sell to engineering managers when starting a new project.
      • ngrilly 2y ago
        That's sad, because the language looks fantastic.
        • neonsunset 2y ago
          F# is absolutely alright. It has a small but nice community and various libraries that follow similar pattern - the selection may be small but the product is usually high quality. It is a predominantly community-developed language. Microsoft contributes engineers to ensure that F# works, slowly evolves and is able to consume all the new APIs introduced in C#, while community drives the evolution of F#'s own features. You can write your own RFC, have it pass through the review, get signed off by Don Syme and then, once approved, implement it (or have it implemented by someone else). Each new release usually has multiple features driven by F# community this way. Give it a try and if you have questions - feel free to ask them on F# discord.
      • exceptione 2y ago
        Ionide and Rider are other options too. But I thought the broken F# support in VS is a thing of the past now? Imho the bigger problem is that the C# language designer continue to not take F# into account. Structs and SUM types could be a shared MSIL story perhaps.
• jchw 2y ago
  I am a certified Go zealot; pretty much anyone who's trolled through enough threads here can attest to that. However, I am increasingly interested in .NET these days. I think Microsoft and the .NET community have built something truly compelling, and the language design of C# is superb (and I'm not saying it's perfect by any means, but I'm routinely impressed with what they accomplish version over version.) My only hangup is that I have had my confidence shaken by Microsoft's occasional showing of hand: with the foundation drama, the debugger nonsense, and with the weird CLI live reload removal, it seems there's still some shades of old Microsoft hanging around. I don't honestly believe they'd pull a complete bait-and-switch, and let's face it, Go is backed almost entirely by Google, a company that is at least as difficult to trust in the long run, but I wish they would, or perhaps could, do something to send a strong signal that they won't meddle with things anymore. What they have done with open sourcing .NET is highly mutually beneficial to Microsoft, and I won't lie that I think it was a greater service to us than them in some regards... but at the risk of sounding greedy here, I need to be able to trust that the people in charge are not going to pull any funny business if I'm going to invest my time, effort and possibly business into an ecosystem. > There are some - debatable - arguments that static typing reduces bugs. [...] I think the key benefit for me is what it enables in terms of reading and maintaining code. I find that static types help me understand the intent and implementation of half-remembered or unfamiliar code much more quickly. But, that's a large part of how it helps reduce bugs, in my opinion. The other part is that static typing can legitimately disallow certain classes of runtime errors, but obviously that doesn't in and of itself guarantee that code is overall less buggy. In practice, though, at least as far as reducing runtime crashes, JS with TypeScript has been night-and-day better than without. Maybe static typing itself is not actually guaranteed to reduce bugs, but in practice any system that can replace bits of "Just Don't Make Mistakes" with diagnostics is going to improve reliability. The only case where I have ever questioned it was MyPy, and that's because I feel the MyPy type system is just not powerful enough to properly cover the vast majority of idiomatic Python (or it requires too much effort.) If MyPy was more sophisticated, though, there's just no doubt in my mind on that one. All in all though I do think C# is a good choice for a productive environment to write code in. Modern .NET has a good ecosystem of tools, libraries, and frameworks, impressive language design going on in its most popular languages, and it's honestly pretty good in terms of performance and scalability. While "right tool for the right job" is a little over-indexed on, I do think that Rust occupies a bit of a different space than C#/.NET. Rust remains king for very high performance, minimal overhead, and safe concurrency; it's got very few direct competitors. You certainly could use Rust for anything you could do in C#, but I think C# is ultimately more productive. This is not hate towards Rust, though, as I personally am the type of person that finds the value proposition of Rust very appealing and I certainly plan on investing more into Rust in the future. A better comparison for C# is Go: I think they occupy a surprisingly similar space for all of their differences. And in that realm, C# compares shockingly favorably, especially modern C# on modern .NET.
• danielodievich 2y ago
  I went skiing at Big Sky with bunch of Microsofties as part of Microsoft ski club back in 1999. One of them was a pretty big guy who on the first day of skiing took a bad tumble and threw out his knee. He had to stay at the chalet for most of the rest of the trip, missing out on some glorious snow. I remember asking him what he did while recuperating and he showed me what became .NET. He said it was going to be awesome and transformational, with many other nice adjectives. I didn't really get that from his demo, it was pretty rough, but yeah, he was right. I've been Csharping almost every workday since it came out as 1.0 and its an excellent framework, especially these days where it runs everywhere.
• romaniitedomum 2y ago
  Honestly, this reads more like someone who wanted to use C# from the outset and needed to come up with reasons to justify it, rather than an honest comparison of a number of languages and platforms with a view to selecting the best fit for the problem domain. None of the listed reasons for choosing C# are unique to C# or its ecosystem. And some of them seem to have been discovered to be applicable only after the fact. For instance, productivity is listed as the top reason, but his team only found C#/dotNET to be the most productive after using it. They didn't know it would be the most productive in advance. So it wasn't a reason for choosing that platform. Other reasons listed are, 1 Open Source, 2. Cross Platform, 3. Popularity, 4. Memory Safety, 5. Garbage Collection, 6. Stability, 7. Statically-Typed, 8. Batteries Included, 9. Tooling, and 10. Performance. I think there are plenty of languages and platforms that are as good as C#/dotNET in all of these areas, but there's nothing here to suggest any of them were even considered.
  • smashedtoatoms 2y ago
    I'd have written this exact comment two years ago. After two years using C# and .NET in anger, I'd pick it for almost any project. It's better than Python, Ruby, Go, Elixir, Typescript, Etc. and better than Rust unless you absolutely must squeeze every ounce of performance out of something, and even then, sometimes C# is better. I know it's not cool, but I spend very little time on distracting stupid shit in C#. No other ecosystem does it as well as .NET. It seems like such a low bar, yet almost no one can get over it. I sit down to program for what feels like 30 minutes in a moment of inspiration, and I look up and it's been 5 hours and I got more done than I was expecting. Every other language often has me dealing with some distraction having nothing to do with the actual problem I'm hoping to solve, and sometimes robbing me of the desire to solve the problem at all. Other languages drive me to mess with my editor config, because it's more fun than trying to convince my environment that a business problem is more important to solve than why some dependency that was importing fine a week ago is now broken. Other languages have me trying to get AI to build me something I've built before without typing any code. C# wants me to ship something quickly that works and it wants to help me do it. It's a remarkable ecosystem, and it makes it really hard to put up with the hoops the others make me jump through. 5/5, would .NET again.
• neonsunset 2y ago
  Nice! C# is also a secret systems programming language in a way that competing GC-based languages are not. It’s actually very nice for high load environments. With the caveat that, much like in Rust, you have to actively vet your dependencies and sometimes write your own optimal implementations, which C# enables incredibly well with precise control over memory management, first-class structs, zero-cost abstractions, SIMD and a compiler that is slowly closing the gap with LLVM.
  • Bognar 2y ago
    Agree. We're using C# in the backend for an MMO, and while I would still like _more_ control over the memory management, there's a ton of options for dropping down to a low level and avoiding the GC. Stuff like ReadOnlySpan and IMemoryOwner are awesome to have as built-in language concepts.
• ThinkBeat 2y ago
  One of the problems with C# is the constant expansion of the language. Microsoft wants it to be everything for everybody, instead of sharpening it in one direction. If you have a lot of experience in C# 2.0, later code may be quite incomprehensible. (Yes this goes for other versions vs the latest version as well) Whereas I can pick up a C program today and have a decent understanding of what it is doing. Then the codebase becomes legacy a lot faster than most other environments. It will compile and keep it, but programmers want to stick new features into the codebase. F# to the limited extent I have followed it seems more stable in terms of added features. C# has certainly adopted a lot of features from F". My second big gripe with Net is EF ORM. If the developers using it are not reasonably aware of how a relational database works, you can get truly horrific code. A dev team at a client I was at, managed to spike the SQL Server instance to damn near 100% for at least 30 mins. When someone discovered the what and where was causing it. A pure SQL statement replicating what needed to be done ran in seconds.
  • PeterStuer 2y ago
    .NET 's initial appeal was that it felt like Java before the architecture astronauts and the bloat with a saner GUI approach to boot. These days they not only caught up but are trying to surpass in those areas. It seems to be the doomcycle of life in development stacks. Fresh system cuts through the accumulated cruft of the old, only to gather more and more niche cruft until it collapses on a beach of arcanary while the next wave of simplicity rises behind it.
    • zeroc8 2y ago
      Java has been doing great recently and I feel there is a bit of a renaissance going on. There is a very mature leadership at the helm and it shows. With .NET, it seems that they've added features too quickly without giving it enough thought up front. If you are a small team or working on a short lived project, this might not matter. But for long lived projects by large teams, I'd rather take the more conservative approach.
      • jeroenhd 2y ago
• PeterStuer 2y ago
  "Tracebit is a B2B SaaS Security Product. If you did a straw poll of Engineers - especially readers of a certain orange website - about the ‘best’ language for such a system, I think the common responses would include Python, TypeScript, Golang, Rust, something JVM-y, maybe Elixir" I guess everyone likes to be the underdog, but thruth is the B2B space is dominated by the duopoly of Java and .Net and shows no signs of changing. The author is imho cosplaying as a contrarian while being solidly mainstream.
  • miki123211 2y ago
    I think C# has the highest ratio of (happy) programmers to internet discussions, at least among mainstream languages. This makes it look a lot less popular and cool for people outside the ecosystem. I think that it's also much more common with companies that aren't primarily tech-focused, as those companies usually have cosy relationships with Microsoft. Pure tech companies, startups and FAANGs don't seem to use it much. This also ties into geography. In the US, far more people work for startups, FAANGs and pure tech companies than in Europe, where traditional businesses and "software houses" are far more prevalent, which means there's far more C# there.
    • neonsunset 2y ago
      Which is a shame, because C# is usually better at the problems many startups try to make Go work at. It is a significantly stronger offering if you treat it as a middle ground between C++ and Rust family and Go/Java family. It is the cool and modern language in today's landscape. But it is popular among the companies which use it the opposite way. Now, we shouldn't complain too much. Because this is what made .NET survive in the first place. But I wish more people looked at projects like Garnet, Ryujinx, various greenfield HPC and highload libraries in the ecosystem over yet another CRUD template. Business domain modeling is much better done in F# anyway!
      • rednafi 2y ago
        I can understand advocating for C# over the mess that is JavaScript, but with Go, it’s a different story. Startups choose Go because no one I know is excited about working with GoF-style OO code these days. It’s easier to hire for and faster than C# for most workloads. Yes, you can write C# in a data-oriented way, but no one does. So diving into an existing codebase means dealing with OO encumbrances, and not everyone wants that. The compilation time is fast, and so is the startup time. Cross-platform compilation with a single command and a single binary makes life easier. On top of that, most infra tooling—Grafana, Prometheus, Kubernetes, Terraform—is written in Go, so choosing Go for the backend comes with a ton of advantages over C#. I can personally attest that this is exactly why Uber and now DoorDash have chosen Go over the alternatives.
• account-5 2y ago
  My only experience of C#/.Net programming is by way of powershell. But the comments here make me think it would be a good idea to invest some time in learning c# beyond what it can provide over add-type in powershell. I've mostly avoided it because I thought it was windows only, I've learned dart and flutter for cross platform programming. Can c# run on mobiles?
  • Hawxy 2y ago
    C# runs on practically everything these days. See Avalonia: https://avaloniaui.net/ https://avaloniaui.net/
  • zigzag312 2y ago
    Yes. MonoGame (written in C#) for example supports iOS, iPadOS, Android, macOS, Linux, PlayStation 4, PlayStation 5, PlayStation Vita, Xbox One, Xbox Series X/S and Nintendo Switch.
  • jdthedisciple 2y ago
    > Can c# run on mobiles? Yes: Google Maui Cross Platform App Dev
• rednafi 2y ago
  C# is a nice language, but it has a huge surface area in terms of syntax. Also, Microsoft’s past behavior makes a lot of people avoid it entirely before even considering it. Plus, many, like myself, just don’t want to write OO code, no matter what. I simply don’t want to spend my time working that way. This makes hiring difficult, especially when many young engineers who start their careers with non-OO languages instinctively shy away from Java-esque languages. That said, I welcome language diversity in the backend and love that new startups no longer default to Node. I’d rather deal with OO than fiddle with a poorly designed language that was never meant for anything but throwaway frontend code.
  • pjmlp 2y ago
    This leaves very few mainstream languages left like C available, as everything else does support some form of OOP, regardless of the shape it is exposed on the programming language type system. OOP is not going away from mainstream.
    • rednafi 2y ago
      Most modern codebases in Node and Python are devoid of OO—at least in the ones I’ve worked on over the last half-decade. Go is mainstream now too, and it doesn’t even allow writing OO code. People love Python because it’s still one of the easiest languages to start with, as it doesn’t force any particular coding style on you. Underneath, it supports a bastardized version of OO, but it doesn’t care if you just use simple types and pass them around to mostly free-floating, stateless functions. This is how startups write Python anyway. Add a huge ecosystem of libraries and a fairly well-designed type system, and you’ll appeal to a ton of people—despite being quite sluggish. C# and Java struggle to attract this crowd, which is gradually becoming the majority as the industry ages.
      • ngrilly 2y ago
        I’ve learned programming with OOP in Turbo Pascal, C++ and Java. Switching to a different programming style, more data-oriented, using free-floating functions, in languages such as Python, Go, or more recently Zig, has been liberating. I have inherited a C# code base and I have to say that I’m not super excited about going back to using classes and objects everywhere. It’s really hard for me now to “unsee” the problem with that unnecessary complexity.
• timeoperator 2y ago
  "Performance is rarely the primary reason to choose a language, but it’s certainly a nice bonus." (X) Doubt
  • IshKebab 2y ago
    F, but yes. I think it often isn't the primary reason (look at how much crap is written in Python or Ruby) but I wouldn't say "rarely" or we wouldn't have so much code written in C/C++. It's probably true to say it is rarely the primary consideration in B2B backends.
• pjmlp 2y ago
  Great post, instead of the usual rewrite X in Y, because reasons.
• begueradj 2y ago
  This article is very useful because the author shares his thought process as why he picked C# over languages he is familiar with (such as Python), or something trendy as Rust. I wish more articles like this one would pop up every now and then here and elsewhere.
• _pdp_ 2y ago
  The developer knew how to program in C# - end of story.
  • deleted 2y ago
    [deleted]
• ngrilly 2y ago
  I recently inherited a C# code base at work. I agree that C# is a powerful, productive, and mature language, but as someone who has been programming mainly in Go, Python, and a bit of Zig over the past few years, there are a few things that feel like a regression in C#: - The absence of free-floating functions (everything is an object, and I must use static methods on static classes). - When “using” a namespace, the convention is to make all the symbols in the “used” namespace available directly in the current namespace. That makes harder to know where symbols are coming from when reading code. And to avoid name collisions, people tend to use longer names. The convention in Go or Rust is to prefix most symbols with the package they are coming from. But perhaps I’m missing something and need to read/write more C#. - The syntax for doc comments with tags such as <summary> is super verbose. I don’t see the point. Docs are working great without these tags in other languages. Reminds me of my J2EE days. - I really prefer the name before type syntax (used in all new languages such as Go, TypeScript, Go, Swift, Kotlin, Zig, etc.) to the type before name syntax (used in C#, C, C++, Java, Dart).
  • Genbox 2y ago
    C# started as a language tightly aligned with C++/Java, but has since moved to be something else entirely that is highly capable. I assume that free-floating functions are global functions. You can achieve something similar by "global using". Put this in a file and tug it away somewhere: "global using static YourStaticClass;" Now you can call all the static methods on the class everywhere. As for the using vs. naming convention, most people use the IDE and hover the mouse over the type to see its identity. Once you get proficient with the IDE, you can do it using shortcuts. However, if you really want to prefix all types with a shorthand of the package it came from, you can do it with aliases in C#.
    • lordofgibbons 2y ago
      > I assume that free-floating functions are global functions. In most languages they're bound to some scope, like package, module, etc. I'm not familiar with C#, but I assume there it would be scoped in a namespace.
• knallfrosch 2y ago
  If Microsoft released a new version and called it something other than asp.net, .net, .net framework, .net core or anything like that, I'd be so happy. Finding outdated search results from 2012 is probably the biggest impediment for the ecosystem. Or finding out, from the project XML, whether a project is .net48 and Windows only or .net6 I'd a non-trivial task. Why? Other than that, I agree with the article. It's a mature ecosystem where the crucial bits have first-party support.
• _7acn 2y ago
  In my opinion, one of the most underrated things by people programming in C# is the fact that they also have F# at their fingertips. They ignore it because they haven't dedicated enough time to appreciate how powerful and fantastic it is.
  • mhh__ 2y ago
    F# is indeed pretty good. C# should be but they're allergic to making things beautiful.
  • Capricorn2481 2y ago
    > They ignore it because they haven't dedicated enough time to appreciate how powerful and fantastic it is It's less that and more things that work in C# will not work in F#, and the community doesn't have enough support for it. If you use .NET for its tooling, you lose some of that with F# and wonder if you should just use a different ML language. Want Entity Framework on F#? Code generation is broken past .NET 6. Huge pain in the ass to fix. Using Dapper is fine, but EF is nice for more than avoiding SQL. Want Swagger support on Giraffe? They're rethinking the whole structure just to imagine how that would work. It's very much a separate world unless you use a lot of C# directly, and that kinda defeats the point.
    • neonsunset 2y ago
      You phrase this as if many other features are broken which is untrue. What you listed is one of the few problematic areas.
• ilitirit 2y ago
  I have used a myriad of programming languages in production in my nearly 25 years of professional programming. There are things I love (almost never "hate") about most languages. But the reason C# is one of my favourite languages to code in professionally is simply because of how easy it is to setup the environment and just get to work. Admittedly on Windows, but I've learned over the last 5 years it's a pretty simliar experience on Linux too. No messing with environment variables or paths; no header file wrangling; no macro shenanigans; no messing with virtual memory settings etc etc etc. Yeah, I get it. Choice is nice. But when it comes to my job what's most important is that I can just get to work.
  • mystified5016 2y ago
    The C# Linux experience is spending five minutes googling how to install the dotnet SDK on your distro because they're all different. Then you install the IDE. We're a windows shop at work, but because C# is portable, I get to use Linux to do my development. It's really nice
    • neonsunset 2y ago
      Sad Debian noises. Most of the time, `sudo apt install dotnet9` (or whichever metapackage version you need) just works. And then you open up a VS Code or a Rider it's ready to go, but yeah.
• yohbho 2y ago
  Free as in beer? Is Mono free as in free beer, or .NET, which at any time can be commercialized?
  • Rohansi 2y ago
    .NET is fully open source on GitHub under the MIT license.
    • pier25 2y ago
      Yeah since 2016
• skeeter2020 2y ago
  C# really benefited from the trail that Java broke, and has stumbled in similar areas, notably the UI space. I know people who love Blazor but it's not for me. MAUI just looks like MSFT's latest cover fire & delay strategy; not going to get me again. But if you're writing primarily backend code in modern .Net C# is very productive, refreshingly lightweight, pretty much complete and has great tooling and lots of taleneted developers in the ecosystem.
  • caspper69 2y ago
    MS UI has been a mess for years. They just can't pick a paradigm to run with apparently, so people just fall back to good ole' Winforms. That being said, check out Avalonia: https://avaloniaui.net/ https://avaloniaui.net/ and https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia Cross-platform, open source, MVVM & reactive. A breath of fresh air.
• coder543 2y ago
  I have never had a chance to use C# professionally, but it was one of the first languages I taught myself when I was first learning programming when I was a kid. I have a lot of fond memories of it, and I hear so many positive things about C# and .NET Core these days… but I just don’t see very many interesting tech jobs where I would have the chance to use C#. So, I’ve mostly used Go, Rust, and TypeScript through my career up to this point. If anyone wants to point me to some good C# opportunities, I’m interested. (Tracebit is looking for a founding engineer, so presumably they want someone who is already an expert at C#, and I doubt they want to sponsor the visa work needed to bring someone to the UK.)
• EMM_386 2y ago
  I've been working with C# since 2001, which is when it came out of beta stage and into production-ready. My last greenfield product I was able to choose the stack (except the database, which I was stuck with). Front-end? Angular, mostly because I felt it fit best with experienced .Net developers. Back-end API layer? C#, obviosly. So I've been working with C# for 24 years. No regrets.
  • arnonejoe 2y ago
    I’m in the same boat. I worked on a project with Microsoft Consulting Services when the .Net Beta 1.0 was released in 2001. I felt very lucky to be employed at the time (post 9/11, .com bubble bust) and also getting paid to work in the latest stack. Like you I have no regrets.
• deleted 2y ago
  [deleted]
• noveltyaccount 2y ago
  As the author points out, Batteries Included is a big reason I choose C# over and over again. Every time I have to go to NPM or Crates.io and look over five or more packages to solve some seemingly basic problem I get exhausted and frustrated that I'm not actually solving the problem I need to. C# has so much built in, and while there are third party options, the Microsoft way is almost always good enough.
  • t_tsonev 2y ago
    Recently I've got bitten by the comically poor cross-platform cryptography support in .NET Just look at https://learn.microsoft.com/en-us/dotnet/standard/security/cross-platform-cryptography https://learn.microsoft.com/en-us/dotnet/standard/security/c... and https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls https://learn.microsoft.com/en-us/dotnet/framework/network-p... for a sneak peek into this madness.
    • littlecranky67 2y ago
      You should be good when using .NET 9 and openssl 3.0+?
    • neonsunset 2y ago
      These limitations come from cryptographic implementations provided by specific platforms, not from .NET. Can you list specific algorithms you need that are not supported? The second article uses the wrong link too (it's for Framework, not for .NET).
      • jeroenhd 2y ago
        As someone with no horse in this race, I must say that I'm a little disappointed in the way Linux "compatibility" deals with platform differences. Most parts of the crypto API seem to be marked as "works on Linux if/except when" which seems strange given that porting to macOS didn't seem to impose such restrictions. In some cases, the inner workings of the underlying library works differently and you get an exception when using certain functionality on Linux at all. I though Microsoft did better porting dotnet to Linux. I knew they don't care about Linux GUI, but I hoped they'd at least do system libraries better.
• germandiago 2y ago
  How does C# compare to Clojure, at which I am looking lately a lot with a wish to use it for distributed applications productivity-wise, concurrency-wise and productivity-wise, including deployments in production?
  • doorhammer 2y ago
    C# and Clojure are probably my two favorite languages, but I've done much much less Clojure in production, and for my personal disposition C# is my overall favorite. For bread-and-butter concurrency (make a bunch of external service calls at once, collect them up and do something) you've got async/await, but you probably knew that. Some other things you might look into as far as distributed/parallel libraries/frameworks go: - Orleans, a framework for using an actor model in C# to build distributed systems - TPL Dataflow (Task Parallel Library), a lib for composing "blocks" to create parallel dataflow graphs Productivity wise, the tooling for C# imo is pretty top notch, and I'd just be repeating what the article said. Something I radically prefer about Clojure is the LISP heritage of highly interactive debugging and app dev. You can get great feedback loops with C#, but it won't be what you can do with Clojure and Calva or Cursive (is cursive still a thing? it's been awhile) On the other hand, I personally prefer strongly typed languages, especially with C#, because of how good some of the static analysis and refactoring tooling can get in things like Rider (a JetBrains IDE for C#). I think deployments are going to be a toss up. For my money Go is still the gold standard of "just make a binary and chuck it out there" and Clojure and C# are more normal "once you're used to it, it's completely fine, but it won't blow you away"
• brainzap 2y ago
  The tooling argument is contradicting itself: You need a big fat IDE to work with c#. Profiling is not even part of the default tooling, Microsoft tutorials want you to upload profiles to external flamegraph tools etc.
  • pier25 2y ago
    > You need a big fat IDE to work with c# Depends on what you do. For backend APIs I thought I'd need Rider (I'm on macOS) but I've been happy using VSCode. I suppose for MAUI or Windows desktop it's different though.
  • neonsunset 2y ago
    > You need a big fat IDE to work with c# This is completely false. On a Mac: brew install --cask visual-studio-code brew install dotnet + install base C# extension. That's all you need to get a language server, a debugger and the full SDK. It can rename symbols, step into implementations, apply standard refactorings, etc. For profiling there are dotnet-trace, dotnet-metrics and various utilities to visualize the traces. You can even wire all that to pprof on Linux. JetBrains tools are very nice but they are by no means a requirement.
    • hombre_fatal 2y ago
      While they were probably talking about editing code in a big fat IDE, your instructions still install a big fat IDE just to have a language server. Edit: Oops, I'm wrong. I saw visual-studio-code but read visual-studio.
      • ziml77 2y ago
        If you consider VSC a fat IDE (at half a gigabyte) then just install OmniSharp on its own.
    • mystified5016 2y ago
      I used to work on a game where one of the mechanics was that you could write your own C# scripts. In a text box. We compiled the code in the game engine with Roslyn. You don't need an IDE for C# any more than you do for any other language. You can use literally any form of text editing. We use IDEs because they make the job easier.
• npodbielski 2y ago
  TPL seems fine in documentation but I found it very hard to be used in real world scenario. Wiring evrything to single input-output or using dozens Join blocks to achieve data structure you want for some blocks was not pleasant. Also finishing pipeline in the right time is also not that easy. Either blocks were not finishing at all or finishing too early. I end up writing my own flow library that is much easier to use for simpler pipelines, yes not so versatile and does not allow spanning multiple inputs across multiple blocks, but at least it does what it supposed too.
  • neonsunset 2y ago
    Nobody uses System.Threading.Tasks.Dataflow. How do you even stumble upon it??
• doorhammer 2y ago
  Tangentially related: When I was doing C# on Windows full time I ended up using LINQPad a ton for almost all of my daily scripting. LINQ + MoreLinq + Extension Methods makes it really easy and fast to make type safe internal DSLs that I wouldn't want anyone I care about to have to use but worked really well for personal power tooling. (you also _can_ definitely write more sane ones, but I didn't have to for personal stuff and it let me burn off the cleverness in my brain before working on code other people might have to work with)
  • kkukshtel 2y ago
    Can you say more about how you made a DSL this way? I love C# but one of my (few) issues with it is that its “support” for DSLs is generally subpar compared to the JVM and how Kotlin and Java files can exist side by side in the same project. Would love to know tips about how you approach this!
    • doorhammer 2y ago
      Yeah, for sure! So I should say I'm playing a bit fast and loose with "internal DSL" here, so that might have been a little misleading. I'm not doing anything fancy like you could do in Scala or Ruby where there are a lot of powerful things you can do to change language syntax. The main pieces of C# I composed to get what I'm talking are: LINQ/MoreLinq: For my scripting I was almost always automating some kind of a process against collections of things, like performing git actions against a mess of repos, performing an XML transform against a bunch of app.configs, etc. Extension Methods: Because you can add extensions methods that only appear if the collection you're operating on is a specific _type_ of collection. So I could have an extension method with a signature like this: `public static void Kill(this IEnumerable<Process> processes)` and then I could do this: `Process.GetProcessesByName("node").Kill();` (I didn't test that code, but in principle I know it works). Kind of contrived, because there are a million ways to do that, but it let me create very terse and specific method chains that imo were pretty obvious. The last thing, that's a lot more finicky and I didn't use as often, but very powerful are ExpressionTrees: https://learn.microsoft.com/en-us/dotnet/csharp/advanced-topics/expression-trees/ https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top... This is what EF and a lot of other libraries use to generate queries, though you can generate whatever in principle. It's basically a first class mechanism for passing a lambda into a method and instead getting an AST representation of the lambda that you can then do whatever with. E.g., traverse the AST and generate a SQL query or whatever. (apologies if I'm explaining things you already know) Lmk if I'm missing what you're asking. Like I said, I'm definitely being a little lazy with the DSL moniker, especially compared to something like something you'd make in JetBrains MPS or a DSL workbench, or language where you can more powerfully modify syntax, but above is generally what I meant.
• LeFantome 2y ago
  C# is one of my favourite languages and .NET is an awesome stack top to bottom. The interoperability between F# (a fantastic functional) language and C# is a real bonus that was just touched on in this article. Writing a compiler for .NET is easy and fun as you can target CIL (Common Intermediate Language) either as binary or text (.NET assembly basically). Something that builds in .NET today will probably run 20 years from now but faster. Another benefit that is really stands out once you start using it is that you can write anything in it. It integrates to C well and you can get absolute control over the bits in memory and on disk if you want. You can avoid the garbage collector most entirely where you think you need to. You can also operate at a high level of abstraction. It has, if anything, way too many web and GUI frameworks (even just from Microsoft). And that last part is the rub… The downside of C# is that it is both old and rapidly evolving. That means multiple competing frameworks. That means that the complexity of the language keeps increasing. It is not quite C++ (and WAY better designed) but it has the same problem. The number of features and the breadth of syntax is non-trivial. There is also a bit of “magic” that has crept in that allows you to skip boiler-plate with the side-effect of basically have behaviour you cannot see in the code. All this is optional. If you write everything green field with some coding standards, it is no problem. But if you want to read other people’s code, there is a fair bit of language to learn. Like English, C# is incredibly useful and can be used anywhere. Like English, it is super easy to pick up and use. Like English, it feels like you can use it your whole life and still not know it all.
  • ycombinatrix 2y ago
    >Like English, it is super easy to pick up and use. Um. Have you tried learning English? This is definitely not the case.
• arrty88 2y ago
  i love dotnet / c# and i would love to work with it again. i have been in the typescript/node world for the past 10 or so years, and while productive, it leaves much to be desired.
• idatum 2y ago
  I was pleasantly surprised to see FreeBSD part of the list of available cross-platforms running .NET. I already had a FreeBSD instance for ZFS and was able to also host a website and some workloads written in C#, avoiding the need for a separate Linux instance. https://wiki.freebsd.org/.NET https://wiki.freebsd.org/.NET
• thdhhghgbhy 2y ago
  Haven't written C# for 8 years, but Visual Studio used to be dog slow. But that's the only criticism I can think of, love the language. I remember when ReactiveX came out, C# became close to unbeatable at that point.
  • _7acn 2y ago
    JetBrains Rider is free for non-commercial use, oh and VSCode is decent too
• sirjaz 2y ago
  I hate people always raging on Windows, but I love that they embraced .Net and C#. Windows outside of its cost has a more advanced kernel, note WSL1.
  • exceptione 2y ago
    I am a sophisticated man: .net good, windows bad. .net being cross platform is its saving grace.
• tester756 2y ago
  I've started programming in C++ and when I encountered C# then my initial reaction was: Wow, this language allows me to focus on writing programs (algorithms) instead of fighting with the language! 9 years passed by, now 'veI worked with C, C++ and C# for money and my opinion is still the same. I've earned way, way more money in C/C++ world, but I was 5x times happier / saner in C# world.
• ansgri 2y ago
  I didn't follow it close, but had an impression that C# and .Net still have a significant Windows ecosystem bias. But this article, and comments from happy C# users, may just convince me to re-learn modern C# and start using it in everyday work. I'm kinda tired of C++/Python ecosystem, and have fond memories of working with C# around 2.0-3.0.