Product Launch
anonymous
10 points
2 comments
Postedabout 1 month agoActive26 days ago
Lowtype
codeberg.orglaunchedlibraryRuby developers
Key Features
Elegant type definitionsType checking for Ruby
Tech Stack
Ruby
Ruby
Key Features
Tech Stack
def method(thing: String | "default value")
I like that over-flexibility... it's regularly too clever and makes it difficult to follow the flow of an application, but I like it all the same.
Too much magic means nobody can understand the code anymore.
Most people who design DSLs don't understand this. It's a problem in ruby - ruby's syntax is so flexible that one ends up with kind of dialects in it.
My knee-jerk reaction is "yes I'd like that" but when I pause to think about how I actually write Ruby code... hmm. I tend to use Ruby when its flexible syntax and type system are helpful. How much would I actually benefit from something that restricts the flexibility of the type system?
Bear in mind, I'm not a "Ruby dev" per se. It's a well-loved tool in my mostly firmware-focused repetoire. I use it for little CLI tools, and toy game engines too (mri embeds into C really cleanly). Fun little things that most folks would use Python for, I just like Ruby better.
Exactly because of the concerns you described, RBS originally used only separate files for the type annotations, so it can be selectively and gradually applied. You can add Ruby signatures inline as comments as well, but frankly both options looks ugly, and so does many of the alternatives like Sorbet signatures.
But over time, I've grown to love it. Programming is communication—not just with the machine, but with other developers and/or future me. Communicating what types are expected, what types are delivered, and doing so in a natural, inline, graceful way? Feels a big win.
IME not until there was a sufficiently clean, direct, and common way to add typing (PEP 484 and its follow-ons) did the community actually coalesce, standardize, and practically start to use type information on a broad basis. We needed there to be one default way of sufficient attractiveness, not 14 competing, often incompatible, and rather inconvenient options.
You may look at built-in typing as a way to communicate with interpreters, compilers, type-checking and linting tools, and/or editor language support engines. Certainly the old purely static typing languages looked at them this way, out of necessity. The compiler, linker, loader, ABI chain has to know the bit-width of your objects, and pronto, because they're going right on the stack!
But in a highly dynamic language that doesn't strictly need types to run the code, typing works as much a signal to future me and my colleagues and collaborators as it is to any mechanism or tool. It signals structure and intent that we'd otherwise have to intuit or decipher. That some tools can use it too, just as they do in fully static languages, is great and useful but not the whole enchilada.
After having worked with gradual typing, unless the application is very disciplined, IMO automated testing is not enough to document the code, as Ruby makes it very easy to use flexible data structures which very easily become messy.
I work on big Ruby on Rails monoliths and I curse every day that I don't have types to work with. It's almost a requirement for large refactors.
For some reason some people want to slap down types onto EVERY language. I call them the type-o-maniacs.
For both though I have questions:
A. How do I use this day to day to improve my tooling and developer experience?
B. If at some point in the future I decide to get rid of this how easy is it to eject?
I've seen too many adandoned dependencies over the years to trust anything I can't easily remove when it's time to upgrade.
These runtime typing efforts look nicer than Sorbet but, as far as I can see, you still have to have complete test coverage to trigger runtime checks if you want to spot correctness issues before you deploy into production.
Sorbet doesn't have that problem right now. Maybe something clever using Prism might be a way round that?
I think you're right, and if that's the case, aren't these libraries (Lowtype, Literal) more akin to Design by Contract mechanisms?
But I have a hard time believing ruby-core will want to hear community feedback... Ruby is omakase?
RBS and Sorbet suck. One is very limited, the other isn't part of ruby-core and makes you rewrite the function arguments again, similar to Java's annotations... Doesn't look like Ruby at all, or DRY, mostly like a workaround!
I disagree that this here should be part of ruby-core, largely because I don't think any of this type madness should infiltrate ruby.
Ruby does not necessarily follow "DRY" - that appears to have been coined by either DHH or the pickaxe guys. More than one way to do it, is kind of orthogonal to DRY too. Note: I do not disagree that DRY has value. What I am saying is that ruby's design does not necessarily follow DRY as a guiding principle.
> hard to believe we are in 2025 and we still don't have a decent, programmer-friendly solution in ruby-core.
I do not think the year has anything to do with it. If they suck - and types suck - then they should not be in ruby core. I understand you have another opinion, but that's the beauty - we have orthogonal opinions there. One says must be part of ruby core; the other says should not be part of ruby-core ever, no matter the year.
> Meanwhile Python has it right since a long time.
The question is: how many use it there?
> No wonder it is so stagnated with people going for other stacks.
Lack of types aren't the reason ruby declined. That is a wrong assumption here.
> Ruby is slowly becoming what Perl did, a very niche language.
That is true, but not due to lack of types. Python without types would still be at rank #1 at TIOBE for instance. Your analysis is simply wrong here.
I tried once myself to implement something like lowtype, but without success.
My general thoughts is that declaring types in Ruby is unnecessarily complicated, because you're basically just running values through pieces of boolean logic, and nothing else. Might as well make that explicit, which is what my experiment did. I didn't however publish the types library, but the concept was proven.
I'd be interested in hearing your opinions on other runtime approaches like contracts.ruby, literal.fun and LowType of course.
I wrote this controversial thought[1] once, but for what it's worth, it applied to me just as much as to anyone else. Projects like these type gems are incredibly fun and satisfying to build. Your vision is clear, you've seen types before, you're proficient enough with Ruby to do clever things. The work seems cut out for you. Go nuts!
Problem is, these kinds of solutions (I also see this in "service objects" world) take Ruby away from you, and offer you a whole new vocabulary. With time I started appreciating libraries that avoid solving a problem that plain Ruby can solve, because Ruby is incredibly clear and concise already. If you leave more opportunities for people to write plain Ruby, you will solve everything with much less library code.
I think that's where the fun of building goes against the end developer experience. Builders love "owning" everything. E.g, "No, don't write `&&`, I have a special way for you to compose types!"
These are general thoughts, but I'm happy to get concrete with specific examples too.
1. Parse the files with a Ruby parser, collect all method definition nodes
2. Using location information in the parsed AST, and the source text of the that was parsed, splice the parameters into two lambda expressions, like this[1]:
"-> (#{method_node.parameters.slice}) {}"
4. In the body of the second lambda, use the `lambda.parameters` of the first lambda in combination with `binding.get_local_variable(param_name)`. This allows you to get the runtime value of the statically-parsed default parameters.
This is an interesting and ambitious architecture.
I had though in the past about how you might be able to get such a syntax to work in pure Ruby, but gave up because there is no built-in reflection API to get the parameter default values—the `Method#parameters` and `UnboundMethod#parameters` methods only give you the names of the parameters and whether they are optional or required, not their default values if they are optional.
This approach, being powered by `binding` and string splicing, suffers from problems where a name like `String` might mean `::String` in one context, or `OuterClass::String` in another context. For example:
class MyClass
include LowType
class String; end
def say_hello(greeting: String); end
end
MyClass.new.say_hello(greeting: "hello")
An author could correct this by fully-qualifying the constant:
class MyClass
include LowType
class String; end
def say_hello(greeting: MyClass::String); end
end
MyClass.new.say_hello(greeting: "hello") # => ArgumentTypeError
Anyways, overall:
- I'm very impressed by the ingenuity of the approach - I'm glad to see more interest in types in Ruby, both for runtime type checking and syntax explorations for type annotations
[1] https://codeberg.org/Iow/type/src/branch/main/lib/definition...
what I have done successfully here https://github.com/radiospiel/simple-service/blob/master/lib... is to install a TracePoint which immediately throws, and then call the method. The tracepoint then receives the value of the default arguments.
Not pretty, and I wouldn't run this in production critical parts of a system, but it works.
A remarkably high proportion of folks that self-identify as Ruby aficionados will make this error.
Also looks awful - not as bad as RBS but awful still.
More please! =)
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.