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

151–155 of 155 posts

Re: T-Ruby is Ruby with syntax for types

#151

Post by rurban »

ReflectedImage wrote: post #149
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.

Absolutely not. Duck type based development results in working code out of the door 3x faster than static type based development. It always has since ancient times. If performance wasn't an issue, then the static type based developers would all be fired. Either directly or by the businesses who relied on them getting driven into bankruptcy by their competitors. You would still get some niche jobs in it where they lik…

I am talking about gradual typing here. Types are optional, if not given or implied they default to any. No need to annotate anything. If given they are enforced, and lead to optimized op codes and errors if violated. Some at compile-time, some at run-time. If fully typed, all errors are caught at compile-time already.

Duck typing as done with python is the worst of both worlds. No optimizations, no enforcement. Just optional external typechecks.

Of course untyped code (ie runtime types in each var) is to write faster. You only need to add types to some vars or args, and gradually improve from there. Eg ints only, because they are optimized the easiest. No need to check for strings, bigint, floats,.... Or arrays to check for overflows at compile-time and restrict to ints or strings. Massive improvements possible, in size and runtime.

Or object fields. Hash lookups vs static offsets.

Re: T-Ruby is Ruby with syntax for types

#152

Post by zingar »

sethhochberg wrote: post #130
zingar wrote: post #67

Earlier quoted context omitted.

I don’t think the existence of a library to do something is evidence of the community shifting. For me the complete absence of types from any Ruby I see IRL or in examples from conference talks, readmes etc is evidence that the community is uninterested despite tons of effort from big players.

I think there's some real sample bias in that definition of "the community" though, because people who are passionate Ruby programmers giving conference talks, running meetups, etc are often a distinctly different group than the regular-old programmers making business software go 'round every day. The big players writing tools for bringing various flavors of type safety into Ruby are doing it because they're experien…

I’ve work as a consultant for a few different tier 2 Ruby organizations and many startups myself and haven’t seen any typing in production. I suppose reconciling our different experience requires data about whether “most” Ruby programmers are at the giants or are spread out over the long tail of startups and scale-ups.

Re: T-Ruby is Ruby with syntax for types

#153

Post by ReflectedImage »

rurban wrote: post #151
ReflectedImage wrote: post #149

Earlier quoted context omitted.

Absolutely not. Duck type based development results in working code out of the door 3x faster than static type based development. It always has since ancient times. If performance wasn't an issue, then the static type based developers would all be fired. Either directly or by the businesses who relied on them getting driven into bankruptcy by their competitors. You would still get some niche jobs in it where they lik…

I am talking about gradual typing here. Types are optional, if not given or implied they default to any. No need to annotate anything. If given they are enforced, and lead to optimized op codes and errors if violated. Some at compile-time, some at run-time. If fully typed, all errors are caught at compile-time already. Duck typing as done with python is the worst of both worlds. No optimizations, no enforcement. Just…

If JITs hadn't been invented you would be completely right but JITs have been invented.

There are deeper optimizations that JITs can do such as knowing at runtime that the value of a variable is always 2 that typing information simply can't express.

Duck typed Python is optimal for development speeds, the only thing that matters in startup environments. It has it's niche.

You aren't gradually improving, you are gradually deteriorating the codebase to make it look more familar to you.

Re: T-Ruby is Ruby with syntax for types

#154

Post by dudeinjapan »

dismalaf wrote: post #125
dudeinjapan wrote: post #70

Earlier quoted context omitted.

Two reasons. First, YJIT/ZJIT do much better when they know the type signatures of methods. You pay a performance penalty for implicit polymorphism, e.g. using a mix of types (Integer, Symbol, String) etc in the same method argument. Second, from my experience with Typescript, as much as I naturally dislike type declarations, I find it does help LLMs. Having strongly typed libs/gems and being able to mix in untyped a…

> First, YJIT/ZJIT do much better when they know the type signatures of methods. The running interpreter knows the type of objects. Ruby isn't untyped. The annotations do nothing for the interpreter.

I meant to say: strict “ahead-of-time” static typing would help a theoretical successor to Y/ZJIT—not the current JITs in their as-is form.
Post reply on HN