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

131–140 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#131

Post by Faark »

cutler wrote: post #107
adimitrov wrote: post #104

Earlier quoted context omitted.

The way to reduce clutter in strongly, statically typed languages is to use strong, robust type inference. For example, Java is pretty terrible at type inference (still) and you have to annotate types almost everywhere (Java 8 had a very tepid improvement on that front.) But languages like Haskell and Rust are very good at type inference, and you almost never actually need to specify the types. It's still good Haskel…

There's nothing lost by putting the sig in a companion file and leaving it to your editor/IDE to provide a popup. Java 10 and 11 introduced real type inference, at least for local variables and function parameters.

> There's nothing lost by putting the sig in a companion file and leaving it to your editor/IDE to provide a popup.

I don't want to go back to having to keep C header file in sync. Your IDE can hide that information from your as well, if you don't want to see it all the time.

Re: Types will be part of Ruby 3 stdlib source

#132

Post by uryga »

mratzloff wrote: post #106
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

As long as types can be required to be explicit where ambiguous (e.g., TypeScript) in the file itself (via a magic comment or similar), I'm all for it. I am happy to declare types for external calls if I need to. I have said for awhile that "Ruby with types" would be my favorite language to work in. I recently returned to Ruby briefly and had to integrate with a poorly-documented API. I spent more time digging throug…

i haven't used it, but have you looked at the Crystal language? i think the idea is basically "statically typed Ruby".

Re: Types will be part of Ruby 3 stdlib source

#133

Post by mnarayan01 »

cutler wrote: post #110
mnarayan01 wrote: post #100

Earlier quoted context omitted.

The parser thinks that's a block not a hash.

Right, so why not implement the sig as a block and keep the syntax concise - the Ruby Way.

Then you'd need an extra set of delimiters, e.g.:

  sig {{name: String, returns: Integer}}

Re: Types will be part of Ruby 3 stdlib source

#134

Post by bjoli »

aasasd wrote: post #111
bjoli wrote: post #77

Earlier quoted context omitted.

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.

> It is no worse than python Eeeeeeeh…

Python and ruby have about the same speed for most common tasks (or at least in the same ballpark), IE: dirt slow once you leave the comfort of the fast parts of the runtime that are written in C.

In reality this is fast enough for most tasks.

Re: Types will be part of Ruby 3 stdlib source

#135

Post by znpy »

_hardwaregeek wrote: post #6

Very cool! I didn't think this would happen, as Matz has expressed disinterest in adding type annotations. However, keeping an open mind and reconsidering one's positions are the hallmarks of a great leader :D I worked on a summer project to add type annotations to Ruby. Didn't get very far since I ran into some challenges with the internals of the parser and the parser library, Ripper. I'm extremely interested in se…

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.

Re: Types will be part of Ruby 3 stdlib source

#136

Post by fouc »

mratzloff wrote: post #106
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

As long as types can be required to be explicit where ambiguous (e.g., TypeScript) in the file itself (via a magic comment or similar), I'm all for it. I am happy to declare types for external calls if I need to. I have said for awhile that "Ruby with types" would be my favorite language to work in. I recently returned to Ruby briefly and had to integrate with a poorly-documented API. I spent more time digging throug…

Could elixir be a good alternative? It has typespecs https://elixir-lang.org/getting-started/typespecs-and-behavi...

Re: Types will be part of Ruby 3 stdlib source

#137

Post by vemv »

cutler wrote: post #102
didibus wrote: post #10

It's an interesting turn of event that Ruby, Python and JavaScript are all getting types. Meanwhile, I've gotten myself more and more into Clojure. Which now that other dynamic languages seems to move closer to types, seems to be in a niche in that Clojure is moving further away from types. It'll be interesting to see what happens at both extremes and in the happy middles.

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

Yes, clojure.spec enjoys a great momentum and acceptance in the community. It's being used for a great deal of use cases from safety to generative testing to HTTP params coercion.

Re: Types will be part of Ruby 3 stdlib source

#138

Post by aasasd »

bjoli wrote: post #134
aasasd wrote: post #111

Earlier quoted context omitted.

> It is no worse than python Eeeeeeeh…

Python and ruby have about the same speed for most common tasks (or at least in the same ballpark), IE: dirt slow once you leave the comfort of the fast parts of the runtime that are written in C. In reality this is fast enough for most tasks.

The thing is, I do some Python programming for money, and I'm having a hard time imagining what the Brew team did to make `brew search` and its other parts so slow. I'd probably have to compare strings byte by byte in Python code for that.

Might have to learn me some Ruby just to figure out this mystery.

Re: Types will be part of Ruby 3 stdlib source

#139

Post by vemv »

Partnering with Ruby Core is a bit dubious for a project which is still closed source.

Why the privacy? Are programmers too dumb to understand something is a beta?

What if in the end adoption is marginal and Ruby Core's time was wasted?

Best adoption is organic, not hyped up.

Post reply on HN