5 ms·

I've been a ruby dev for 15+ years; i'd really love it if ruby adopted a C# similar approach to typing (albeit, more ruby-like and more flexible). It's the most

I've been a ruby dev for 15+ years; i'd really love it if ruby adopted a C# similar approach to typing (albeit, more ruby-like and more flexible). It's the most readable, simplest way I would enjoy as a rubyist. Everything else (including sorbet) feels bolted on, cumbersome and cringe. I appreciate the article and how it goes over the constraints; but genuinely sorbet is just not good enough from a DSL standpoint. Type's can be fun and useful, and i'd love to see them incorporated into ruby in a tasteful way. i don't want it to become a new thing developers are forced to do, but there is a lot of utility from making them more available.

dismalaf 1y ago
C#, ew. Crystal (Ruby but statically typed) has nicer type syntax. Or Pony. Or Nim, Odin, and others.
- usernamed7 1y ago
  Hrm, i think this is a good point, It might be something better served by a ruby-like alternative. I'll have to tinker with crystal sometime. Thanks for this comment!
- ksec 1y ago
  Crystal still has tooling problems and compiling time problem. Both not easily solvable. May be Kagi will grow to certain size some day they could invest back into Crystal.
emn13 1y ago
While I'm most familiar with C#, and haven't used Ruby professionally for almost a decade now, I think we'd be better off looking at typescript, for at least 3 reasons, probably more. 1. Flowsensitivity: It's a sure thing that in a dynamic language people use coding conventions that fit naturally to the runtime-checked nature of those types. That makes flow-sensitive typing really important. 2. Duck typing: dynamic languages and certainly ruby codebases I knew often use ducktyping. That works really well in something like typescript, including really simple features such as type-intersections and unions, but those features aren't present in C#. 3. Proof by survival: typescript is empirically a huge success. They're doing something right when it comes to retrospectively bolting on static types in a dynamic language. Almost certainly there are more things than I can think of off the top of my head. Even though I prefer C# to typescript or ruby _personally_ for most tasks, I don't think it's perfect, nor is it likely a good crib-sheet for historically dynamic languages looking to add a bit of static typing - at least, IMHO. Bit of a tangent, but there was a talk by anders hejlsberg as to why they're porting the TS compiler to Go (and implicitly not C#) - https://www.youtube.com/watch?v=10qowKUW82U https://www.youtube.com/watch?v=10qowKUW82U - I think it's worth recognizing the kind of stuff that goes into these choices that's inevitably not obvious at first glance. It's not about the "best" lanugage in a vacuum, it's a about the best tool for _your_ job and _your_ team.
- Kinrany 1y ago
  Tangent, has C# recovered from nulls being included in all reference types by default?
  - neonsunset 1y ago
    Yes. It will complain if you assign one to something that isn't T?. For the best experience you may want to add `<WarningsAsErrors>nullable</WarningsAsErrors>` to .csproj file.
  - emn13 1y ago
    "Recovered" sounds so binary. I think it's pretty usuable now, but there is scarring. The solution would have been much nicer had it been around from day one; especially surrounding generics and constraints. It's not _entirely_ sound, nor can it warn about most mistakes when those are in the "here-be-dragons" annotations in generic code. The flow sensitive bit is quite nice, but not as powerful as in e.g. typescript, and sometimes the differences hurt. It's got weird gotcha interactions with value-types, for instance but likely not limited to interaction with generics that aren't constrained to struct but _do_ allow nullable usage for ref types. Support in reflection is present, but it's not a "real" type, and so everything works differently, and hence you'll see that code leveraging reflection that needs to deal with this kind of stuff tends to have special considerations for ref type vs. value-type nullabilty, and it often leaks out into API consumers too - not sure if that's just a practical limitation or a fundamental one, but it's very common anyhow. There wasn't last I looked code that allowed runtime checking for incorrect nulls in non-nullable marked fields, which is particularly annoying if there's even an iota of not-yet annoted or incorrectly annotated code, including e.g. stuff like deserialization. Related features like TS Partial<> are missing, and that means that expressing concepts like POCOs that are in the process of being initialized but aren't yet is a real pain; most code that does that in the wild is not typesafe. Still, if you engage constructively and are willing to massage your patterns and habbits you can surely get like 99% type-checkable code, and that's still a really good help.
    - neonsunset 1y ago
nightpool 1y ago
What parts of a C# approach do you think Ruby should adopt? The syntax? I don't think anyone thinks of C# as having a particularly good or noteworthy type syntax or features—anything you can find in C# you can probably find in most other typed languages. I'm curious what specifically you think C#'s typing system is better at than e.g. Typescript, Python or Rust
uticus 1y ago
> i'd really love it if ruby adopted a C# similar approach to typing interesting that you've called out C# as the specific example of a way to approach typing. c# did nothing new with their typing system, instead copied from java and others https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java#Types https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java...
- deleted 1y ago
  [deleted]
tomcam 1y ago
“Flexible” scares me with regard to types. Can you elaborate on that thought?

dismalaf 1y ago

C#, ew. Crystal (Ruby but statically typed) has nicer type syntax. Or Pony. Or Nim, Odin, and others.

usernamed7 1y ago
Hrm, i think this is a good point, It might be something better served by a ruby-like alternative. I'll have to tinker with crystal sometime. Thanks for this comment!
ksec 1y ago
Crystal still has tooling problems and compiling time problem. Both not easily solvable. May be Kagi will grow to certain size some day they could invest back into Crystal.

emn13 1y ago

While I'm most familiar with C#, and haven't used Ruby professionally for almost a decade now, I think we'd be better off looking at typescript, for at least 3 reasons, probably more. 1. Flowsensitivity: It's a sure thing that in a dynamic language people use coding conventions that fit naturally to the runtime-checked nature of those types. That makes flow-sensitive typing really important. 2. Duck typing: dynamic languages and certainly ruby codebases I knew often use ducktyping. That works really well in something like typescript, including really simple features such as type-intersections and unions, but those features aren't present in C#. 3. Proof by survival: typescript is empirically a huge success. They're doing something right when it comes to retrospectively bolting on static types in a dynamic language. Almost certainly there are more things than I can think of off the top of my head. Even though I prefer C# to typescript or ruby _personally_ for most tasks, I don't think it's perfect, nor is it likely a good crib-sheet for historically dynamic languages looking to add a bit of static typing - at least, IMHO. Bit of a tangent, but there was a talk by anders hejlsberg as to why they're porting the TS compiler to Go (and implicitly not C#) - https://www.youtube.com/watch?v=10qowKUW82U https://www.youtube.com/watch?v=10qowKUW82U - I think it's worth recognizing the kind of stuff that goes into these choices that's inevitably not obvious at first glance. It's not about the "best" lanugage in a vacuum, it's a about the best tool for _your_ job and _your_ team.

Kinrany 1y ago
Tangent, has C# recovered from nulls being included in all reference types by default?
- neonsunset 1y ago
  Yes. It will complain if you assign one to something that isn't T?. For the best experience you may want to add `<WarningsAsErrors>nullable</WarningsAsErrors>` to .csproj file.
- emn13 1y ago
  "Recovered" sounds so binary. I think it's pretty usuable now, but there is scarring. The solution would have been much nicer had it been around from day one; especially surrounding generics and constraints. It's not _entirely_ sound, nor can it warn about most mistakes when those are in the "here-be-dragons" annotations in generic code. The flow sensitive bit is quite nice, but not as powerful as in e.g. typescript, and sometimes the differences hurt. It's got weird gotcha interactions with value-types, for instance but likely not limited to interaction with generics that aren't constrained to struct but _do_ allow nullable usage for ref types. Support in reflection is present, but it's not a "real" type, and so everything works differently, and hence you'll see that code leveraging reflection that needs to deal with this kind of stuff tends to have special considerations for ref type vs. value-type nullabilty, and it often leaks out into API consumers too - not sure if that's just a practical limitation or a fundamental one, but it's very common anyhow. There wasn't last I looked code that allowed runtime checking for incorrect nulls in non-nullable marked fields, which is particularly annoying if there's even an iota of not-yet annoted or incorrectly annotated code, including e.g. stuff like deserialization. Related features like TS Partial<> are missing, and that means that expressing concepts like POCOs that are in the process of being initialized but aren't yet is a real pain; most code that does that in the wild is not typesafe. Still, if you engage constructively and are willing to massage your patterns and habbits you can surely get like 99% type-checkable code, and that's still a really good help.
  - neonsunset 1y ago

nightpool 1y ago

What parts of a C# approach do you think Ruby should adopt? The syntax? I don't think anyone thinks of C# as having a particularly good or noteworthy type syntax or features—anything you can find in C# you can probably find in most other typed languages. I'm curious what specifically you think C#'s typing system is better at than e.g. Typescript, Python or Rust

uticus 1y ago

> i'd really love it if ruby adopted a C# similar approach to typing interesting that you've called out C# as the specific example of a way to approach typing. c# did nothing new with their typing system, instead copied from java and others https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java#Types https://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java...

deleted 1y ago
[deleted]

tomcam 1y ago

“Flexible” scares me with regard to types. Can you elaborate on that thought?