this post was submitted on 09 Jun 2024
229 points (79.7% liked)

> Greentext

7394 readers
7 users here now

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 75 points 2 months ago* (last edited 2 months ago) (4 children)

pervasive unchecked nullability

Framework management is hell, fat binaries inconvenient and not default

No option monad in the standard lib

Cross version dependencies simply don't work in some contexts

Compiler output only marginally better than working with c++

At least it doesn't have Gradle.

[–] [email protected] 15 points 2 months ago (2 children)

pervasive unchecked nullability

Addressed nowadays with the question mark and exclamation mark syntax, and programming without nullability is a pain

Framework management is hell, fat binaries inconvenient and not default

Nuget?

Compiler output only marginally better than working with c++

No one claims it's faster at runtime than good C++, it's just a lot easier to write decent code

[–] [email protected] 6 points 2 months ago (1 children)

Compiler output only marginally better than working with c++

No one claims it's faster at runtime than good C++, it's just a lot easier to write decent code

I think they're referring to warning and error content. Compared to things like rust, deciphering error notifications from the c# compiler can sometimes feel like trying to figure out what a child with limited vocabulary is trying to tell you.

Even with decades of personal experience with it, they can be confusing and non-informative sometimes for me.

[–] [email protected] 3 points 2 months ago

Yes this is right. C++ in this context is the boogeyman worst possible scenario. C# only being a little better just means it's not actual garbage

[–] [email protected] 4 points 2 months ago

Nullable reference types are (a completely mandatory) bandaid fix in my opinion as a .net dev. You will encounter lots of edge cases where the compiler is unable to determine the nullability of an object, e.g. when using dependency injection to populate a field, or when using other unusual control flows like MediatR. You can suppress the warnings manually at the slight risk of lying to the analyzer. Objects supplied by external library code may or may not be annotated, and they may or may not be annotated correctly. The lack of compile-time null checking is occasionally an issue. But that said, NRT makes nullability a significantly smaller issue in C# than it used to be

[–] [email protected] 9 points 2 months ago (1 children)

Null reference checking by the compiler is enabled by default in new C# projects.

C# doesn’t come with an option monad in its standard library, but its cooler sibling F# does.

[–] [email protected] 1 points 2 months ago (2 children)

You can also easily write your own option monad or use a tiny library that does.

[–] [email protected] 2 points 2 months ago (1 children)

Good idea, then patch the whole standard library and dotmet framework and most popular libraries to use that tiny library

[–] [email protected] 0 points 2 months ago (1 children)

You don't need to use the same one. Just don't expose it publicly in libraries.

[–] [email protected] 0 points 2 months ago (1 children)

This is the stupidest thing I've read all day

[–] [email protected] 0 points 2 months ago
[–] [email protected] -1 points 2 months ago

Yeah, 100%. I don't really recognize the complaint that "it isn't in the standard library" as being super valid. If you know what an option monad is and you want to use one, you can certainly create one. Lots of people don't know what it is and won't miss it, especially in this context since the option monad is a functional construct and C# is an objects-first language.

[–] [email protected] 1 points 2 months ago

No Gradle

I have such a love hate relationship with Gradle... I forget exactly what but there was something Maven couldn't do that made me first try Gradle locally. I didn't use it professionally for so long.

Now that I am using it professionally, I'm not sure it's better. Maybe it's just a case of "grass is always greener on the other side" sort of thing.

Some of my gripes,

  1. The documentation is almost really useful, but as soon as you have to look at Gradle's Javadoc it's a mess.
  2. I like the kotlin stuff better than groovy but a lot of old guides still use groovy and sometimes it is very confusing trying to translate.
  3. Why the hell does IntelliJ Idea Professional version still not give me code hints for Groovy Gradle files???
  4. I love that everything is customizable, but I think slightly more concrete conventions would be useful a lot of times. Or at least documenting the conventions somewhere.
  5. Why is it so hard to get the Maven BOM experience? There's always fucking edge cases. Plus, why can't I do it with plugins too?
  6. Why is there no "task tree" by default? Why isn't this part of Gradle? https://github.com/dorongold/gradle-task-tree
  7. Why the fuck is JPMS so confusing? This is probably not really Gradle's fault but still.
  8. Why is upgrading the wrapper so complicated? I have to do two invocations and get the version string myself.