[znpy]

I honestly think that more than Matz reconsidering his own opinions, it probably turned out that having types is an instrumental thing to enable performance improvements.

Keep in mind, Ruby development is headed towards a goal that the dev team has called "3x3" as in Ruby 3 aims to be three times faster than current Ruby implementation.

[Arubis]

My recollection is that 3x3 is a goal to be 3x faster than Ruby 2.0–presumably many of those gains have already been realized, so best not to depend on tripling _current_ performance.

[jamie_ca]

Yeah, the NES emulator that's one of the benchmarks is about 1.8x faster so far, so only another 1.6x to go on top of that.

[olah_1]

>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.

[viraptor]

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.

[fjp]

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.

[delaaxe]

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

[fjp]

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.

[lizmat]

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.

[joesb]

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.

[lizmat]

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.

[olah_1]

>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.

[lizmat]

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.