Types will be part of Ruby 3 stdlib source • Hacker News Board

Re: Types will be part of Ruby 3 stdlib source

#211

Post by techsin101 » Mon, Apr 22, 2019, 1:22 AM UTC

simplify wrote: post #174

techsin101 wrote: post #168

Earlier quoted context omitted.

Tell me few .. to me types were useful for hinting in ide but vscode already gives good hints

Types are not just for autocompleting, but also for making illegal states unrepresentable[0]. For example, let's say you have Question model with two types: MultipleChoice and ShortAnswer. In TypeScript you can model it like this: type MultipleChoice = { mode: 'mc' body: string choices: string[] expectedAnswer: number } type ShortAnswer = { mode: 'sa' body: string exampleAnswer: string } type Question = MultipleChoic…

this indeed looks useful. so you can give multiple types by using '|' ? and if there is vagueness compiler will let you know.. mind blown.

Re: Types will be part of Ruby 3 stdlib source

#212

Post by joesb » Mon, Apr 22, 2019, 8:43 AM UTC

lizmat wrote: post #170

viraptor wrote: post #150

Earlier quoted context omitted.

It depends what do the type annotations do. I'm not sure how perl6 does it, but for example in python type annotations are completely ignored at runtime, so don't have any impact. We'll see how much / for what does Ruby 3 actually want to use the type information. Sorbet on its own is unlikely to affect runtime either.

Type checking is runtime, although if the static optimizer can figure out that a certain call will never work at compile time, it will throw a compile time error.

On the other hand, if the static optimizer can figure out that a certain call will always work at compile time, it can remove the runtime check for that part.

Re: Types will be part of Ruby 3 stdlib source

#213

Post by fjp » Mon, Apr 22, 2019, 2:19 PM UTC

delaaxe wrote: post #185

fjp wrote: post #180

Earlier quoted context omitted.

Going to keep praying for type/performance optimizations in Python so we can all get past the "python is slow" thing. Async python is an absolute joy to develop with.

Care to elaborate which type of work you're doing and which libraries you're using?

Libraries:

aiohttp: web framework

aiopg: async postgres driver with SQLAlchemy support

asyncssh: async ssh library with SFTP capability

I generally work on CRUD microservices to automate some steps of a business workflow - activating/registering a resource with our vendors, generating and updating pricing, picking up new files off an FTP site and processing.

Re: Types will be part of Ruby 3 stdlib source

#214

Post by joelbluminator » Tue, Apr 23, 2019, 6:26 AM UTC

nevertoolate wrote: post #123

joelbluminator wrote: post #74

Earlier quoted context omitted.

I think most rubyists do benefit from dynamic types. How easy would it be to build rspec and Rails in java? The whole dependency injection thing in Spring is in part a by product of types making it way harder to test things. That's just one example.

Can you give a concrete code example you are talking about? What is your problem with DI with spring? Why do you feel it is a problem with static type checker?

What jashmatthews said mostly. It adds bloat and isn't very readable. It's another "ceremony" that together with types, interfaces, generics etc increases lines of code. I can see the benefits for huge projects, but I don't like this way by default out of the box.

Re: Types will be part of Ruby 3 stdlib source

#215

Post by olah_1 » Fri, Apr 26, 2019, 12:12 AM UTC

lizmat wrote: post #169

olah_1 wrote: post #147

Earlier quoted context omitted.

>it probably turned out that having types is an instrumental thing to enable performance improvements. I was disappointed to find out that adding more types in Perl6 actually slows down performance. I wonder what the differences are that adding types in one language speeds it up, while adding types in another language slows it down.

Could you elaborate on how you got to the conclusion that adding types in Perl 6 slows things down? They shouldn't, unless you create types that actually run Perl 6 code during type checking. Which is usually not the case.

>Could you elaborate on how you got to the conclusion that adding types in Perl 6 slows things down?

I was playing around with adding types to everything in my program. Creating kind of a little Haskell style script. I was sad when it ran slower than it did without the types. Someone informed me that that is the expected outcome because (as you said) type checking is done at run time.

Re: Types will be part of Ruby 3 stdlib source

#216

Post by lizmat » Fri, Apr 26, 2019, 8:29 AM UTC

olah_1 wrote: post #215

lizmat wrote: post #169

Earlier quoted context omitted.

Could you elaborate on how you got to the conclusion that adding types in Perl 6 slows things down? They shouldn't, unless you create types that actually run Perl 6 code during type checking. Which is usually not the case.

>Could you elaborate on how you got to the conclusion that adding types in Perl 6 slows things down? I was playing around with adding types to everything in my program. Creating kind of a little Haskell style script. I was sad when it ran slower than it did without the types. Someone informed me that that is the expected outcome because (as you said) type checking is done at run time.

The thing is that even if you do not specify a type, you've implicitly specified the `Any` type. And type checking (which always happens at runtime, whether or not you've explicitly specified any types) will be done against that.

So I'm very curious as to what code exposed a slowdown after explicit types were added.