[HN Gopher] Why Tracebit is written in C#
___________________________________________________________________
Why Tracebit is written in C#
Author : mrcsharp
Score : 72 points
Date : 2025-01-31 23:22 UTC (8 hours ago)
(HTM) web link (tracebit.com)
(TXT) w3m dump (tracebit.com)
| halfcat wrote:
| 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 wrote:
| C# has changed a ton in the last few years, it's definitely 4/4
| for me...
| CharlieDigital wrote:
| It's getting closer and closer to TypeScript.
| yodon wrote:
| You presumably are aware that C# and TypeScript share the
| same original language designer
| CharlieDigital wrote:
| 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.)
| caspper69 wrote:
| 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.
| neonsunset wrote:
| > 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.
|
| Indeed, it's a completely different product nowadays.
|
| Take a look at this! https://learn.microsoft.com/en-
| us/aspnet/core/fundamentals/m...
| unsignedint wrote:
| 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 wrote:
| >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/...
|
| >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.
| unsignedint wrote:
| Yes, but in the case of Python, I feel it's a bit more
| nuanced. Simply having Python installed isn't enough--you
| also have to manage virtual environments (venv, Poetry, or
| whatever is popular at the moment). Personally, I find this
| to be more of an ongoing maintenance burden.
|
| I do acknowledge that .NET has its share of breaking changes
| from time to time, but in my experience, the friction is
| significantly lower compared to other environments I've
| worked with.
|
| > PowerShell is built on .NET (in whatever form .NET
| Framework and .NET/core) lol. It doesn't "share" anything, it
| _IS_ shell for .NET.
|
| I never said it wasn't! I was simply speaking from the
| perspective of the frontend experience. While PowerShell is
| built on .NET, my point was about how its functionality and
| design make it feel familiar to those already accustomed to
| .NET development.
| whoknowsidont wrote:
| >my point was about how its functionality and design make
| it feel familiar to those already accustomed to .NET
| development.
|
| Because it's literally a "shell" into the .NET
| runtime/framework. PowerShell _extensively_ uses reflection
| capabilities.
|
| My point was they're not sharing some design philosophy or
| converging, PowerShell is just exposing .NET functionality
| directly and in an interactive manner. You in fact, can
| write a pretty similar tool with a few lines of C# that
| makes use of dynamic compilation and reflection.
|
| Otherwise, PowerShell shares nothing (and I mean nothing)
| with other .NET languages (C#, F#, etc). It's history and
| design choices come from things like KornShell and Perl.
|
| Where do you think all those $variables and "-ne" operators
| came from?
| unsignedint wrote:
| Look, I'm not disagreeing with you here. I'm not even
| talking about the internal mechanics--I'm simply
| referring to the user experience. You're fixating on my
| choice of words and taking my point in a direction I
| never intended.
|
| All I'm saying is that knowing .NET makes it easier to
| write PowerShell scripts, and I appreciate that. If
| that's not your experience, that's fine--but that doesn't
| change my perspective.
| rqtwteye wrote:
| I was excited about PowerShell at first but after doing a mid
| size project it, I don't like it anymore. It's such an odd
| language with too many quirks once you get serious. I think
| they would have been better off using C# syntax.
| billfruit wrote:
| The same is even better with Java.
|
| It's common to find Java binaries build 20 Years+ to run on
| present day systems without issue.
| mgh95 wrote:
| From what I gather, the only time this occurred was very
| early in the C#/.NET ecosystem (.NET2) when generics were
| added in November 2005. So it should be at 20 years this
| year.
|
| Both languages are very impressive and benefit from the
| competition.
| cyberax wrote:
| Early C# often depended on libraries that were MS-specific,
| partially native code, and are often no longer even
| available.
|
| This changed around 2014-ish, as a result C# has been
| really stable for a decade.
| mgh95 wrote:
| Possibly. I'm a relatively recent comer to the c#
| ecosystem (2021ish). It's been good and avoids some of
| the warts of java.
|
| Really, though, I'm _very_ happy there is competition in
| the GC enterprise languages for linux. Regardless of who
| is "better", the competition will continue to drive
| progress in this area.
| porcoda wrote:
| Yup! I recently took a pretty substantial project I wrote in
| 2006 in Java that was sitting in a tar file, unpacked it, and
| it ran just fine with a current JVM. Even better, I was able
| to compile it again with no problems: again, with a modern
| JDK. I wish I could say the same for years of projects
| written in Rust and Haskell: the Haskell ones are almost all
| bit rotten since I haven't kept them up to date with GHC, and
| Rust is similar. Those two are even worse since with Java I
| had a rich standard library, so I didn't have any 3rd party
| dependencies in my 19 year old project. The Haskell and Rust
| ones rely on Hackage and crates, and keeping things working
| for that long would require me to do bonus work beyond my
| actual project code. I've had similar but less painful
| problems in Python land: the library APIs are mostly stable:
| the biggest headache there are projects that predate python3
| so there's some work to bring them up to date. That's at
| least a one time investment.
|
| Java: no bonus work induced by third parties to keep projects
| alive, keeps working for a long time. Would recommend.
| codr7 wrote:
| Makes sense, but Java's mostly portable library eco-system and
| its maturity would make a very strong contender to me.
| GiorgioG wrote:
| As opposed to .NET's mostly portable library ecosystem?
| codr7 wrote:
| Definitely not as mature and portable from my experience.
| metaltyphoon wrote:
| 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 wrote:
| This is supposed to replace JNI from what I gather:
| https://openjdk.org/jeps/442
| sophiacamille wrote:
| 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 wrote:
| 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 wrote:
| C# is my second favourite language, despite it being OOP first.
| My personal fav is F#.
| spicyusername wrote:
| 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 wrote:
| 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 wrote:
| Here's the language proposal for those that are interested.
|
| https://github.com/dotnet/csharplang/issues/8928
| lordofgibbons wrote:
| How does it compare with Kotlin for backend development, which
| inherits all of the JVM ecosystem?
| caspper69 wrote:
| 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 wrote:
| 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 wrote:
| 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...
|
| 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.
| cyberax wrote:
| > Need to quickly put together an application that supports
| enterprise OAuth?
|
| ????
|
| That's super easy. I added support for Clerk's OAuth to our
| app in literally 10 minutes. It was as easy as:
|
| > token, err := jwt.ParseString(sessionToken,
| jwt.WithKeySet(r.keySet), jwt.WithAudience(r.audience))
|
| JWT is from `github.com/lestrrat-go/jwx`
|
| I'm not sure about SAML, but at this point it's probably
| best to not even touch it.
| lordofgibbons wrote:
| I'm complaining about having to use external services to
| do auth, and your solution is to use external services
| lol
| neonsunset wrote:
| OpenJDK used to offer a better baseline performance,
| particularly at very abstraction-heavy enterprise code. .NET
| has closed the gap with it since then. Nowadays, .NET can
| also have quite a Go-like memory profile, especially if you
| use NativeAOT, but has much higher GC throughput which offers
| a more foolproof set of tradeoffs. Go has a nice specialized
| GC design but you cannot tune it at all, and it is centered
| around moderate allocation rates and consistent latency with
| small memory footprint. The moment you step outside its
| boundaries it has problematic regressions .NET's GC
| implementation is robust against. Java GC implementations are
| even stronger, but Java also has _much_ higher allocation
| traffic which offsets some of them.
|
| Where .NET shines is by providing a performance _ceiling_
| completely unmatched by neither Java nor Go nor any other GC-
| based language. Performance ceiling in .NET sits every so
| slightly below Rust and C, in often an indistinguishable way.
| It is a very nice experience to write systems code in. It won
| 't give you the same safety for writing concurrent code Rust
| does, but it is so much more productive than dealing with C
| or C++, especially when it comes to portable builds and
| tooling. Of course, it supports only a tiny fraction of
| platforms compared to C. But your target is more likely to be
| a server or a consumer device or a comparatively beefy
| Raspberry PI, and .NET works really well on all of those.
| cyberax wrote:
| I still prefer Go, for its first-class lightweight threads.
| They make _everything_ so much better to debug, compared to
| async/await that is available in C# and Kotlin.
|
| That being said, Java has recently released Project Loom, but
| it's poorly integrated and often causes subtle issues. It'll
| require a couple more years to mature.
|
| C# doesn't have anything like this for now.
| neonsunset wrote:
| Go is worse at _lightweight_ concurrency because each
| Goroutine is much costlier than each .NET task. Also Go has
| less pleasant concurrency semantics comparatively speaking
| because Goroutines cannot yield a value - you have to spawn a
| channel on top of spawning a Goroutine or you need to use a
| wait group or similar. .NET offers better experience for
| concurrency-centric code at a much lower overhead for code
| that has light of finely grained concurrent operations.
|
| https://hez2010.github.io/async-runtimes-
| benchmarks-2024/tak...
| e3bc54b2 wrote:
| IIRC C# investigated virtual/green threads, but decided to
| drop it because of poor interactions with reentrant code from
| async/await. The fact that C# went all in on async/await when
| it was the rage has prevented it from adopting a better
| solution. Java's conservative attitude fares better for such
| fundamental changes.
| neonsunset wrote:
| There is reason async/await got so popular after it was
| adopted by C# based in the early Async work in F# :)
|
| Stackful coroutines have their pros but they are not a
| better choice. Rust did not and will not adopt them nor any
| other serious systems programming language will.
|
| You don't have to follow noisy style you often see - tasks
| compose nicely and express deferred operations incredibly
| well in a way that will not blow up on you in a surprising
| way.
|
| There is an ongoing Async2 project which will massively
| reduce task state machine overhead further by only ever
| paying for it in the code that actually suspends rather
| than the code that just forwards the calls or doesn't. It
| will likely land as preview in .NET 10 and as full release
| in .NET 11.
| cyberax wrote:
| > Stackful coroutines have their pros but they are not a
| better choice.
|
| Hard disagree. Coroutines are absolutely useless for
| anything non-trivial, as debugging them becomes a total
| hell. They are still a callback hell, just with a lot of
| sugary goo slathered on it.
|
| Coroutines also result in the "colored function" problem,
| that is fundamental for them.
|
| Meanwhile, Go lightweight threads just work. Debugging is
| simple, and you don't have to think about spooky actions
| at a distance from event loops that dispatch coroutines.
| whoknowsidont wrote:
| 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 wrote:
| > 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/ (download the full PDFs)
| whoknowsidont wrote:
| >This is a bad take.
|
| How is being focused on security for a security product a bad
| take?
|
| Did you even read what I wrote or did you come to grunt?
|
| EDIT: Why are you following me around between threads?
| jitl wrote:
| How is c an advisable/respectable choice for a web service &
| cloud orchestrator system?
| whoknowsidont wrote:
| I think you need to look at the product we're talking about.
| jitl wrote:
| I did, it's a thingy that creates tasty looking cloud
| objects ("canaries") in your AWS account and then monitors
| them for suspicious access seemingly by slurping cloudtrail
| logs. C seems like a horrid language for this kind of very
| integration / API / glue heavy domain.
| GiorgioG wrote:
| 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#.
| jchw wrote:
| 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.
| yodon wrote:
| I'd love to hear more on your take on go vs C# at this point in
| time.
| Handy-Man wrote:
| seconded
| DimmieMan wrote:
| > My only hangup is that I have had my confidence shaken by
| Microsoft's occasional showing of hand...
|
| I'll add to the OSS problems of poplar libraries like identity
| server, ImageSharp, Moq and recently Fluent Assertions having
| to change license due to sustainability and got absolutely
| raked through the coals for the audacity of doing so. And the
| general belief that if Microsoft ever release a competing
| product in the same space your cooked even if it's not even
| half as good.
|
| So not only is there the question of trusting Microsoft, my
| confidence is shaken by the wider ecosystem too if fairly
| 'staple' testing libs are struggling in their shadow.
| danielodievich wrote:
| 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 wrote:
| 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 wrote:
| 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.
| smashedtoatoms wrote:
| All that said, you .NET folks need to let your patterns die
| in a fire. Modern C# doesn't require any of this crap
| anymore. Use functions. They're great. The world of nouns is
| behind us.
| neonsunset wrote:
| 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.
___________________________________________________________________
(page generated 2025-02-01 08:00 UTC)