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

Types will be part of Ruby 3 stdlib source

twitter.com

Post reply on HN
Print view View original

71–80 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#71

Post by pmontra »

darkdimius wrote: post #17

We're collaborating with @yukihiro_matz, @mametter, @soutaro and Jeff Forster to make sure that types are not disruptive to Ruby. Thus, types are optional. The intention is to deliver value for unmodified Ruby programs. Hear more from Matz at https://youtu.be/cmOt9HhszCI?t=2148

So, something along the lines of https://github.com/soutaro/steep but without the annotations in the original source code, because Matz said "no annotations". That's nice because it doesn't pollute the code. I use Ruby because of Rails and because I don't have to write types. I can use many other languages if I want to write them.

Re: Types will be part of Ruby 3 stdlib source

#72

Post by viraptor »

trixie_ wrote: post #50
cocochanel wrote: post #15

Why is everything moving to types?

Generally no one uses dynamic typing for the abilities it gives you. Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you? If not then why are you using a dynamically typed language? If you're not using it's abilities then it doesn't sound like the right tool for the jo…

> Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you?

The issue is not "Do you purposefully do those things?", but rather "Do you have a call stack where you can't guarantee it won't happen by accident?" Type checking is not relevant when you know what will happen and want the dynamic/ducktyping behaviour.

Another issue is: I'd use a different framework which doesn't use Ruby, but this was the most productive framework at the time the codebase was started, and nobody will port that many lines of code to a non-dynamic language now. So the best course of action is to validate the current code is not overly-dynamic.

Re: Types will be part of Ruby 3 stdlib source

#73

Post by gmueckl »

eru wrote: post #28
jaequery wrote: post #22

Earlier quoted context omitted.

I don’t know but I hate it. Not sure if I’m in the minority but it sure feels like it. In an ideal world. I feel that types are something that should be dealt with at the IDE level. In fact, there so many things that can be done at that level, but no one has really been brave enough to do so I suppose.

What do you mean by types being dealt with at the IDE level? Depending on your type system, a well-typed program can eg run faster, because the compiler / interpreter can elide certain runtime safety checks that would be necessary in untyped code. If your type system is crazy enough, you can even track the runtime complexity of your program at the type level, including whether your program runs in finite time. See eg…

I think what GP means is that the IDE for a theoretical programming language could automatically infer types and have you not type any code for that explicitly. It might even not show you types as code at all and by default and overlay/add this info only on request.

Generally, there is this huge disconnect between how code is expressed as text and how it is handled in as a graph structure inside the tooling. It is soon time to move beyond simple text files for code, I believe.

Re: Types will be part of Ruby 3 stdlib source

#74

Post by joelbluminator »

trixie_ wrote: post #50
cocochanel wrote: post #15

Why is everything moving to types?

Generally no one uses dynamic typing for the abilities it gives you. Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you? If not then why are you using a dynamically typed language? If you're not using it's abilities then it doesn't sound like the right tool for the jo…

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.

Re: Types will be part of Ruby 3 stdlib source

#75

Post by chrisseaton »

z1mm32m4n wrote: post #55
baybal2 wrote: post #47

Earlier quoted context omitted.

What is the rationale of adding types to a language that will still retain all performance penalties from the need to have dynamic typing code to interact with non-typed data?

Who's to say we couldn't use the types to make the runtime faster in the future? One of the reasons why Sorbet does both runtime checking[1] more than just static checking is so that we can know that signatures are accurate, even when a typed method is called from untyped code. If the signatures are accurate, a future project could take advantage of method's signatures to make decisions about how the code should actu…

I work on an alternative Ruby implementation, and it looks like I'll be able to take these type definitions and use them to add extra type constraints to my intermediate representation very easily - just insert a type constraining node around each expression that's annotated with a type. It'll remove extra guards and increase performance, so should definitely be an option.

Re: Types will be part of Ruby 3 stdlib source

#76

Post by ricardobeat »

I don't use Ruby day-to-day other than a few small tools, but why not focus efforts on evolving Crystal [1] to make it more suited for rapid web development? It already has a powerful type system and incredible performance, and should be an easy transition for rubyists.

[1] https://crystal-lang.org/

Re: Types will be part of Ruby 3 stdlib source

#77

Post by bjoli »

aasasd wrote: post #54
phaedryx wrote: post #8

I recommend whatching "Ruby3: What's Missing?", a presentation Matz gave earlier this month: https://www.youtube.com/watch?v=cmOt9HhszCI This might be misleading. That is, jump to around the 29 minute mark where he talks about the type profiler and .rbi file stuff.

As a user of Homebrew, I just wonder if Ruby's ever going to have performance.

It is no worse than python, but with the 3x3 initiative the main implementation will be a lot faster than today, which will never happen to python unless the current lead will go 180 degrees against what Guido always claimed.

Re: Types will be part of Ruby 3 stdlib source

#78

Post by vnorilo »

baybal2 wrote: post #64
z1mm32m4n wrote: post #55

Earlier quoted context omitted.

Who's to say we couldn't use the types to make the runtime faster in the future? One of the reasons why Sorbet does both runtime checking[1] more than just static checking is so that we can know that signatures are accurate, even when a typed method is called from untyped code. If the signatures are accurate, a future project could take advantage of method's signatures to make decisions about how the code should actu…

I programmed C back in my high school years 14+ years ago. Today I am mostly using JS because it is the cash crop of the industry, and it made me quite some money when I was away from electronics business (my main occupation) for a year after getting troubles with Canadian visas. To me, it feels that there is a very thick wall in between high level languages and something with raw data access like C, C++, and D. You…

Types are the means of "improving language performance" without turning into C. It's all about encoding invariants for the optimizer.

I doubt a competent JIT is ever slower than a competent interpreter, but it may not be that much faster or worth the workload.

It depends on the size of the primitives. An array language could be close to 1:1, while for a cpu-level instructions you will struggle to reach 1/6 of JITted perf.

Re: Types will be part of Ruby 3 stdlib source

#79

Post by IshKebab »

tosh wrote: post #63

I understand why PHP started to add support for type annotations as the hype around type annotations (Dart, Flow and Typescript) still was quite strong a few years ago. By now I think it is quite obvious that type annotations aren’t as helpful as initially expected and that a library approach seems more pragmatic and more powerful. See Clojure + Spec. The thing is dynamically typed languages with type annotations ten…

It's it obvious?

There seems to be a never ending cycle of new languages that are dynamically typed because it is easy for small codebases, which then become popular, get large codebases and then realise that static types are actually a really good idea.

Python, Dart, Ruby, JavaScript (via Typescript), etc...

Re: Types will be part of Ruby 3 stdlib source

#80

Post by gmueckl »

boffinism wrote: post #65
rootlocus wrote: post #40

Earlier quoted context omitted.

By IDE level, you mean compile level. Types are at compile level.

No, types can be at compile level. They can also be checked without compiling any time you like. Or automatically. By an IDE, for example.

Almost all good IDEs are essentially interactive compilers. The lines have blurred during the last two decades. For example, QtCreator and XCode use clang to provide code annotations in the editor. Eclipse is built around ECJ, its own Java compiler, which exists mostly to provide information back to the editor and refactoring tools (the editor maintains a complete bidirectional mapping between code as text and code as AST at all times). Code generation is almost only a byproduct there.
Post reply on HN