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

201–210 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#201

Post by wilg »

aasasd wrote: post #183
wilg wrote: post #182

Earlier quoted context omitted.

Are you using JRuby or something? 10 seconds is too long. > time brew help > brew help 0.55s user 0.26s system 96% cpu 0.849 total

Regular Ruby 2.5.1. I do have a throttled CPU due to no battery in the MacBook, but I still have Python and other stuff to compare, and Brew (or Ruby) definitely does something wrong on my machine. It's hugely CPU-bound without a particular reason for being so.

Weird. I'd guess Brew because MRI Ruby tends to have pretty good boot times.

Re: Types will be part of Ruby 3 stdlib source

#202

Post by codetastik »

chrisseaton wrote: post #75
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 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.

Thank you chris for all your work on Truffle! Looking forward to using it.

Re: Types will be part of Ruby 3 stdlib source

#203

Post by mnarayan01 »

BenMorganIO wrote: post #189
mnarayan01 wrote: post #133

Earlier quoted context omitted.

Then you'd need an extra set of delimiters, e.g.: sig {{name: String, returns: Integer}}

But that would make the hash braces redundant so you could just use parenthesis.

That's a block returning a Hash; see bhuga's sibling comment where he notes that they're using blocks to lazy load the constants in the type definition, which may seem silly for e.g. Integer, but consider e.g. some high-dependency Rails model which requires auto-loading 10,000 other classes.

Re: Types will be part of Ruby 3 stdlib source

#204

Post by fulafel »

didibus wrote: post #175
cutler wrote: post #102

Earlier quoted context omitted.

>Clojure is moving further away from types What about clojure.spec?

I feel Spec is a part of that "move away from types" which I was talking about. It's an approach to software documentation, specification and verification that is at the other end of the spectrum from types. Clojure seems to have double downed on dynamism and runtime construct, away from static types. It seems to have made the bet that better software (less defects, cheaper to maintain and extend, more targeted to th…

It's also an interesting case of language extensibility benefits. Spec is just a library. And its spritual predecessor, Prismatic/Plumatic Schema, was also just a library. This enabled the markers of spec to learn from a body of usage when creating spec with an eye of making it a a standard feature, first as the spec.alpha library and hopefully now the final form.

An always-on static type system could not develop this way.

Re: Types will be part of Ruby 3 stdlib source

#205

Post by Too »

cutler wrote: post #99

The biggest problem for me with gradual typing is code clutter. My favourite languages are Clojure and Ruby precisely because they reduce code clutter. What I would prefer, if we are to have types, is for the signatures to go in a companion file. I've never understood why types have to be inlined. A good IDE can easily provide the signature in a mouseover or something similar.

Types in a companion file?! Every written C/C++ with "companion" header-files? That is clutter my friend.

Half of the documentation will be in the header file and the other half in the implementation file and you will have to edit two files for every tiny change you make. No thanks. Types are part of the code and should be as close to the code as possible to reduce any possible source of friction while editing.

Re: Types will be part of Ruby 3 stdlib source

#206

Post by aasasd »

bjoli wrote: post #77
aasasd wrote: post #54

Earlier quoted context omitted.

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.

By the way, could you please summarize as to what biggest improvements you expect from Ruby that are against Python's policy?

Re: Types will be part of Ruby 3 stdlib source

#207

Post by ricardobeat »

technion wrote: post #95
ricardobeat wrote: post #76

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/

Why should the people who built and maintain Ruby focus their efforts on a different language?

You can ask the creator himself: https://github.com/mruby/mruby

Re: Types will be part of Ruby 3 stdlib source

#208

Post by ksec »

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…

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

That is why we need something that offer 80% the Speed of C, 80% of Simplicity / expressiveness of Javascript / Ruby, and 80% of ease of long term maintenance of a functional PL like Ocaml.

I actually think Java will one day evolve very close to that goal.

Re: Types will be part of Ruby 3 stdlib source

#209

Post by eru »

gmueckl wrote: post #73
eru wrote: post #28

Earlier quoted context omitted.

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 so…

ML family languages (like Haskell) had proper type inference for decades now. And yes, integrating that with your editor/IDE is a good idea.

Depending on what you want to do, you might also want to start with the types and have the computer figure out the implementation.

> It might even not show you types as code at all and by default and overlay/add this info only on request.

Types annotations are often are great documentation, and there's a lot of practical knowledge in the ML communities about what types annotations to show in the source for helping with understand and debugging and which ones to leave out as clutter.

I wrote 'proper type inference' above, because it's much more powerful than the watered down version Go and C++ give you. See eg https://news.ycombinator.com/item?id=8447280 for a Rust example.

Re: Types will be part of Ruby 3 stdlib source

#210

Post by eru »

bfung wrote: post #41
eru wrote: post #27

Earlier quoted context omitted.

I thought the ML family of languages showed that long ago? I guess TypeScript popularized the notion.

ML family has "type inference", which means the compiler figured out the type even if not explicitly written into the code. However, the language spec is still statically typed - an int will not turn into a string and vice versa (ex: "1"). Javascript and ruby, the underlying types can change depending on where the code is in execution - a variable holding a 1 can turn into a "1" and back (implicit type conversion - t…

The alternative view is that those so-called 'dynamically typed' or 'untyped' languages should really be called 'monotyped languages' since all variables and expressions have the same type: a giant union of all possibilities.

See https://news.ycombinator.com/item?id=8206562

Post reply on HN