Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

T-Ruby is Ruby with syntax for types

type-ruby.github.io

Post reply on HN
Print view View original

131–140 of 155 posts

Re: T-Ruby is Ruby with syntax for types

#131

Post by rurban »

dajonker wrote: post #126
rurban wrote: post #114

Earlier quoted context omitted.

Nonsense. You get the simplification and faster development times of knowing some variable types statically, plus the performance improvements for the compiler which can move the type checks from runtime to compile-time. Plus all the new optimization possibilities. Common Lisp showed you the way. But almost none looked at it. Only PHP did.

At least CPython and CRuby (MRI), the most common implementations of each language, ignore all type hints and they are not able to use them for anything during compile or runtime. So the performance argument is complete nonsense for at least these two languages. Both Python and Ruby (the languages themselves) only specify the type hint syntax , but neither specifies anything about checking the actual types. That exer…

Because the anti-types crew showed up and sabotaged it. Similar with perl and lua.

But languages with stronger and more intelligent leadership showed what's possible.

You cannot implement all the compiler optimizations for const and types in extensions. You need to fork it.

Re: T-Ruby is Ruby with syntax for types

#132

Post by bottlepalm »

AI has become my type checker in a way. I'm writing large Python apps now, and not even installing the Python IDE tools into VS Code. The AI assistants generate and refactor my code understanding the types and making it work. Same with JavaScript as well. AI modifies the code, I run/test it. Almost never any bugs related to typing inconsistencies.

I'm not saying we (humans) don't need type checkers and I love TypeScript, but something is happening where AI might theoretically surpass the power of traditional type checking. Have the power to catch even more invalid code than the static analysis tools, linting tools, etc.. we have now.

Re: T-Ruby is Ruby with syntax for types

#133

Post by rurban »

ReflectedImage wrote: post #82
pie_flavor wrote: post #77

Earlier quoted context omitted.

This is junk. Writing a type annotation takes basically zero time, then saves you time by preventing the runtime error because you forgot which variable was which, then saves you more time by autocompleting the correct list of valid methods when you hit dot. Acting like Go is comparable to JS is ridiculous; Go's type system is the only kind of type system needed in Ruby. Rust is a staggering outlier in complexity. An…

Making the type annotations pass restricts you to writing more bloated and verbose programs in general. Stating that A is an integer isn't much of a issue but once you get a reasonably complex program and A now has a compound type made of 5 parts, it really does slow you down and it really does make you write considerably worse programs for the sake of passing a type checker. Any commercial code will need to be unit…

The default type is always any (or dynamic, as some call it). No need to type everything. Usually you type just some args. Not even locals.

And some types can be inferred by the compiler, as e.g. for new instantiators. Or array, int, str convertors.

Re: T-Ruby is Ruby with syntax for types

#134

Post by bitwize »

torben-friis wrote: post #3

Honest question: I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context. But what is the point of the recent wave of types for python, Ruby, and similar languages? If it’s type safety you want there, there’s a bajillion other languages you can use right?

Strong static typing is a must for large scale software engineering. And by "large scale" I mean anything longer or more complicated than like a utility shell script.

These type extensions let you get some of the benefits of static typing for projects already written in Python or Ruby.

Re: T-Ruby is Ruby with syntax for types

#135

Post by k1w1 »

cpeterso wrote: post #129

Is there an advantage for trb code to use colons for type annotations like: def greet(name: String): String Instead of arrows like rbs files? Why diverge from precedent? def greet: (name: String) -> String

Typescript. I imagine most people writing Rails applications are also writing typescript for front-end code, so being able to use the same muscle memory for Ruby typing seems high desirable. That is the thing that stood out to me when I saw this site: it looks like they are taking the very positive lessons from Typescript and applying them to Ruby.

I agree with other posters here. I don't need everything typed - Ruby's duck typing is an awesome feature - but I do wish that some of the more important interfaces in our code were more strongly self-documenting and enforced.

Re: T-Ruby is Ruby with syntax for types

#137

Post by vidarh »

mrinterweb wrote: post #123
vidarh wrote: post #115

Earlier quoted context omitted.

I would strongly oppose mandatory typing for these reasons, but I'm very happy to have stable low level libraries add type annotations.

When I'm writing code that will be distributed to other devs, I feel type annotations make more sense because it helps document the libraries and there is less ambiguity about what a method will take. As with everything, "it depends"

That's true, but it can also add unnecessary constraints if done thoughtlessly.

E.g. if you require an input to be StringIO, instead of requiring an object that responds to "read".

Too often I see people add typing (be it with a project like this, or with is_a? or respond_to?) that makes assumptions about how the caller will want to use it, rather than state actual requirements.

That is why I prefer projects to be very deliberate and cautious about how they use types, and keep it to a minimum.

Re: T-Ruby is Ruby with syntax for types

#138

Post by atomicnumber3 »

yxhuvud wrote: post #90
atomicnumber3 wrote: post #21

Earlier quoted context omitted.

In large - and honestly even medium - and honestly-honestly even _not-small_ python projects, you often end up losing track of what stuff is. At one of my jobs, i was often plagued by not knowing if "f" - short for file, naturally, that part is fine tbh - was a string, an io-like thing, a path object, a file object, or what-have-you. Sure sure, some argue this is the magic of python - just try to do whatever you want…

Honestly, that just seems like a case that would just as well be solved by better naming. Get a linter, tell it to forbid one letter names, and then enforce naming that isn't idiotic when doing pull requests. But yes, there are multiple ways to solve communication problems.

You get dangerously into the "wart" territory from C++.

Another example - in ruby. I really like the Pathname library and use it a lot. Even in my OWN programs, where I almost ALWAYS immediately turn a path into a Pathname, I still find myself calling Pathname functions and getting errors because the type is a string. I've found myself naming parameters - lets say it's a data file - "data_pn" to reassure myself that i should indeed pass in a pathname and not a string.

This is just re-engaging the hungarian notation "warts" pattern in another place and time.

Re: T-Ruby is Ruby with syntax for types

#139

Post by blandflakes »

ReflectedImage wrote: post #86
t-writescode wrote: post #30

Earlier quoted context omitted.

Nah. 99.9% of the people who wanted the addition of DryStructs to a codebase I worked on wanted it because they'd been bit, repeatedly, by someone sending one kind of object into a function rather than what the function accepted and it just not getting caught. A robust type system allows you to make "compiler errors" out of runtime errors. One of these takes *way more tests to catch* than the other. I'll let you gues…

Nah that's just a lack of understanding in the role of unit tests in dynamically typed languages.

Elsewhere in this thread, dynamic typing advocates malign the hassle of maintaining types, and it is always coupled with strong advocacy for an entire class of unit tests I don't have to write in statically typed languages.

Re: T-Ruby is Ruby with syntax for types

#140

Post by ksec »

Lio wrote: post #98
Levitating wrote: post #93

Ugh more transpilers. I think low_type is a much more elegant solution: https://github.com/low-rb/low_type

The problem I see with low-type[1] is that it lacks static analysis to evaulate type usage before runtime and, I don't think, it has any support for tooling so you can't get method usage information in the editor. I think that static analysis could be done with an extension to rubocop via Prism though. Same for documention features via Ruby-LSP tooling. I think if they worked on those they would very quickly pick up…

I remember the author said somewhere ( may be reddit or twitter ) that he is working on those. Low_Type is still in very early stage.
Post reply on HN