Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'd be really interested to see success typing applied to ruby.

http://user.it.uu.se/~kostis/Papers/succ_types.pdf

TL/DR: Success typing considers all possible types a value can have. If a function returns either a bool or an int and you then pass that value into a function that accepts a string or an int, then the success typing checks out. It doesn't mean your program is correct, but that it could possibly be correct. On the other hand, if you pass the "bool or int" value into a function that only accepts a string, the type checker will complain and you know for sure your program is incorrect. In other words, you will get false negatives but never a false positive.



> It doesn't mean your program is correct, but that it could possibly be correct.

That doesn't seem very useful, I already know that my program could "possibly" be correct. If I didn't think so I wouldn't be working on it.

I'm interested in finding out whether it "is" correct or not.

If I ask the type system, and it just shrugs and says "dunno lol" then that type system isn't worth much to me.


It ends up being pretty useful. The number of times it catches problems is pretty high. Also, the more you annotate, the greater the efficacy.

Is it inferior to a full static route system? Yes. Are there benefits to dynamic type systems? Yes. Success typing is a way to get a bit a both.


But how do you know what the function only accepts a string in a dynamic, duck-typed language?


Perhaps more relevantly, in a dynamic, duck-typed language in which methods can be overridden per-object, there is no guarantee that an instance of class String actually implements any given contract (including that implemented by unmodified instances of class String).

So, contracts that specify what functions accept and produce by class membership provide less assurance than they superficially appear to.


Ruby is not a duck-typed language. "duck-typing" is only touted by its community to award it free credibility and merit where there is none. "duck-typing" is essentially free for any dynamic typed language which have method RTTI. So please, stop the "duck-typing" pride parade. It is nauseating.


Huh? If Ruby is not duck-typed, can you give me an example of a something that is? It seems like the textbook example. Here are two weird examples: 1. C++ templates and 2) C# variables declared dynamic (I don't know C#, could be wrong) Are we using the same definitions as each other?


Duck typing is more of a technique than a quality of a language. Any dynamically-typed language is going to end up having some code that does runtime type checking. Duck typing just means doing respond_to? instead of :kind_of? when doing so.

Ruby is certainly a language suitable for the duck typing technique. The term was originally used in reference to Python, and both languages have reasonably equivalent reflection abilities.


I think the point is that duck-typing in Ruby is less of a feature and more of an inevitability due to its dynamic RTTI nature.

Compare that to duck-typing in Go where it was a very deliberate design decision.


Duck typing generally refers exclusively to runtime type checking (i.e. dynamically-typed languages). What Go does is structural typing.


I disagree. C++ templates for instance are also duck-typed, but they act at compile time, not run time.


The same way the contracts gem does it. Annotations.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: