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

81–90 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#81

Post by zmmmmm »

Fascinating to see the circle turn further back towards strong / static typing.

One of the major things that has kept me using Groovy over the last 10 years was the reluctance to leave optional / gradual typing behind. Now, nearly every major dynamic language has given in and introduced types, so it seems like this idea of hybrid dynamic/typed languages is now fully mainstream. The problem of course, is they are all built on a legacy of untyped code, not to mention giant communities of people with no culture or habit of tying their code. So it's not clear to me that any amount of added language features can actually compensate for that.

Re: Types will be part of Ruby 3 stdlib source

#82

Post by Shish2k »

tomc1985 wrote: post #26
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.

So, what, everyone standardizes around an IDE then? You really think that's gonna unite the vim and emacs camps? I'm personally tired of staring at variables trying to figure out what they're supposed to be, then having to dive into source to see how its used. C/C++/C# solved that problem, why are we still dealing with it?

C had some typing, but I'm not going to call it "solved" until "numberOfHats = distanceInPixels + weightInKg" is considered a compile-time error due to the three "int" values being incompatible; but "numberOfHats = aliceHatCount + bobHatCount" is acceptable.

How does nobody(?) support this yet?

Python supports some parts: you can subclass int, and you get all of the int methods like addition and subtraction for free, but "distanceInKm + distanceInKm" gives you an int instead of a distanceInKm; and "distanceInKm + distanceInMiles" gives you an int instead of an error.

Rust also has partial support but from the other end: distanceInMiles and distanceInKm can be two distinct subclasses of int, and adding them together is a compile time error. But also adding distanceInMiles with distanceInMiles is a compiler error, because these are basically "completely new classes" rather than "subclasses of int", and so you have to implement add / subtract / stringify / etc for yourself for every type D: (I'm fairly new to Rust so if there is a shortcut there that I'm missing please do point it out)

Re: Types will be part of Ruby 3 stdlib source

#84

Post by cyberferret »

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/

I agree with this sentiment. I like the type checking in Crystal, and it is pretty much the newer, younger brother to Ruby. I don't see the issue of leaving Ruby pretty much 'as is' so that legacy code does not break, and focus on making Crystal a much better evolution of Ruby.

Re: Types will be part of Ruby 3 stdlib source

#86

Post by Guthur »

snrji wrote: post #62

The trend of adding type annotations to dynamically typed languages is now unstoppable. I wonder if some more exotic features (eg. side effects handling, monads or dependent types) will ever become mainstream in the feature.

It's hardly unstoppable its been there for literally decades. Common lisp had it for a very long time for example and has a few compiler implementations that are really quite sophisticated.

The problem is that most popular dynamic languages are really quite terrible. They have atrocious runtime environments and usually quite limiting language semantics.

Re: Types will be part of Ruby 3 stdlib source

#87

Post by rurban »

baybal2 wrote: post #47
_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…

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?

With types you get more compile-time checks - safer code, better documentation, and the possibility to improve runtime performance and ffi. With a guaranteed int you don't need to check for bignum overflows, and you can avoid all runtime type checks. A typed ffi struct can be used as is for the ffi, raw data. strings are guaranteed to be 0 delimited.

In certain basic blocks typed ints or floats can be unboxed, if they will not escape. This is what php7 made 2x faster. the stack will get much leaner. simple arithmetic ops can be inlined, using native variants. ops with typed vars cannot be overridden.

Re: Types will be part of Ruby 3 stdlib source

#88

Post by rurban »

vnorilo wrote: post #78
baybal2 wrote: post #64

Earlier quoted context omitted.

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…

You forget this is ruby, which will not have a competent JIT. They have such a bad JIT with enormous overhead that only very special cases will be faster, most cases are slower and will wait for locks or be racy.

Re: Types will be part of Ruby 3 stdlib source

#89

Post by cageface »

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…

Types are massively helpful with JavaScript. I’ll never write untyped JS again if I can help it. Switching to typescript has done wonders for my productivity and code quality.
Post reply on HN