4 ms·

Oh, I had no idea jellyfin was based on C#. I started my career as a C# dev, but now I only write C++. I miss C# dearly and have been badly wanting a project t

Oh, I had no idea jellyfin was based on C#. I started my career as a C# dev, but now I only write C++. I miss C# dearly and have been badly wanting a project to flex those muscles on. I guess I'll dive into jellyfin now. I've got a list of annoyances and now that I know it's C#, I'm ready to get fixing

movedx 3y ago
Thank you! I'm not affiliated with the project, but I do use it. I appreciate any and all efforts put toward improving it.
barake 3y ago
You're likely in for a treat if you haven't written C# in a while. The language has evolved quite a bit, especially around all kinds of nice ergonomics. Interesting things like pattern matching, using statements, and performance oriented primitives. I got back to writing C# full time earlier this year and it's a joy.
- _a_a_a_ 3y ago
  I must admit to disliking C#'s functional libraries. I have wasted so much time trying to get the buggers into a pipeline. It becomes agonising in a way that doing the same thing in Scala was so very much a dream. I keep discovering the hard way, just don't do it (or just get a whole lot more experienced at it, although I don't know how without going through the pain barrier, and deeper each time, like Inception). Could you give me a hint about these 'performance oriented primitives' please? (The only ones I can think of are structs versus classes) Edit: but isn't there a new thing where you can subtype a class without allocations, like Scala's record classes, or is that new in Java, can't remember.
- distract8901 3y ago
  I've been keeping up with the language and I am... Less than enthused. Maybe I'm just yelling at clouds, but I see more bloat than useful features recently. Non-nullable reference types as default was a bad idea and I will die on this hill
  - TravHatesMe 3y ago
    > Non-nullable reference types as default was a bad idea Why?
    - distract8901 3y ago
      Lots of reasons, but mainly that I don't consider null values to be a fault of the language. Even if it were, this doesn't solve that problem. But now we're in a situation where we still have nulls, but compiler warnings force us to decorate them and treat them the same as before. It obscures the difference between value and reference types. Plus the syntax implies Nullable<T>, which is something everyone should have learned to avoid when all it did was box value types. The more correct solution would have been to finish the contract system that allowed you to declare a function argument as non-nullable. Ultimately I think it was the wrong solution to something that wasn't a problem to begin with. Now we have muddied the syntax and the null situation is the same as it always has been.
      - _a_a_a_ 3y ago
        Agreed that Microsoft is adding features for the sake of setting C# apart rather than making it a better language (IMO). I strongly disagree about the treatment of null values, if there's one thing I like about C# it's that (even if it's crude, it's better than Scala's way of doing it which is Maybe or Option or something, sorry, it's been a while.) Also C# doesn't 'force' you, you have to require it before it enforces no-nulls. > It obscures the difference between value and reference types How, and how is that a problem? > Plus the syntax implies Nullable<T>, which is something everyone should have learned to avoid when all it did was box value types. Err, now I'm getting really rusty. What are you saying here? > The more correct solution would have been to finish the contract system that allowed you to declare a function argument as non-nullable. That's effectively what the no-null enforcement does, only it applies inside a function as well (if you make it do so anyway). I completely disagree that it "wasn't a problem to begin with" .Hoare called it his billion-dollar mistake, and that's an underestimate. And we haven't muddied the syntax because you enable no-nulls with a pragma, and the null situation is definitely not the same as it has always been. The compiler picks them up and reports them (like I said, rather crappily but it's a damn sight better than nothing).

movedx 3y ago

Thank you! I'm not affiliated with the project, but I do use it. I appreciate any and all efforts put toward improving it.

barake 3y ago

You're likely in for a treat if you haven't written C# in a while. The language has evolved quite a bit, especially around all kinds of nice ergonomics. Interesting things like pattern matching, using statements, and performance oriented primitives. I got back to writing C# full time earlier this year and it's a joy.

_a_a_a_ 3y ago
I must admit to disliking C#'s functional libraries. I have wasted so much time trying to get the buggers into a pipeline. It becomes agonising in a way that doing the same thing in Scala was so very much a dream. I keep discovering the hard way, just don't do it (or just get a whole lot more experienced at it, although I don't know how without going through the pain barrier, and deeper each time, like Inception). Could you give me a hint about these 'performance oriented primitives' please? (The only ones I can think of are structs versus classes) Edit: but isn't there a new thing where you can subtype a class without allocations, like Scala's record classes, or is that new in Java, can't remember.
distract8901 3y ago
I've been keeping up with the language and I am... Less than enthused. Maybe I'm just yelling at clouds, but I see more bloat than useful features recently. Non-nullable reference types as default was a bad idea and I will die on this hill
- TravHatesMe 3y ago
  > Non-nullable reference types as default was a bad idea Why?
  - distract8901 3y ago
    Lots of reasons, but mainly that I don't consider null values to be a fault of the language. Even if it were, this doesn't solve that problem. But now we're in a situation where we still have nulls, but compiler warnings force us to decorate them and treat them the same as before. It obscures the difference between value and reference types. Plus the syntax implies Nullable<T>, which is something everyone should have learned to avoid when all it did was box value types. The more correct solution would have been to finish the contract system that allowed you to declare a function argument as non-nullable. Ultimately I think it was the wrong solution to something that wasn't a problem to begin with. Now we have muddied the syntax and the null situation is the same as it always has been.
    - _a_a_a_ 3y ago
      Agreed that Microsoft is adding features for the sake of setting C# apart rather than making it a better language (IMO). I strongly disagree about the treatment of null values, if there's one thing I like about C# it's that (even if it's crude, it's better than Scala's way of doing it which is Maybe or Option or something, sorry, it's been a while.) Also C# doesn't 'force' you, you have to require it before it enforces no-nulls. > It obscures the difference between value and reference types How, and how is that a problem? > Plus the syntax implies Nullable<T>, which is something everyone should have learned to avoid when all it did was box value types. Err, now I'm getting really rusty. What are you saying here? > The more correct solution would have been to finish the contract system that allowed you to declare a function argument as non-nullable. That's effectively what the no-null enforcement does, only it applies inside a function as well (if you make it do so anyway). I completely disagree that it "wasn't a problem to begin with" .Hoare called it his billion-dollar mistake, and that's an underestimate. And we haven't muddied the syntax because you enable no-nulls with a pragma, and the null situation is definitely not the same as it has always been. The compiler picks them up and reports them (like I said, rather crappily but it's a damn sight better than nothing).