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

91–100 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#91

Post by hrktb »

zmmmmm wrote: post #81

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…

I expect a split between very strictly coded and strongly typed everywhere libraries and shared components, and looser high level scripts mix and matching when convenient.

That could be the best of both worlds.

Re: Types will be part of Ruby 3 stdlib source

#92

Post by bhuga »

cutler wrote: post #83

Instead of: sig {params(name: String).returns(Integer)} ... why not simply: sig {name: String, returns: Integer}

Ruby itself has zero changes from sorbet, so all sorbet syntax has to be valid Ruby. `sig` is implemented as a library.

In this case, your example is not valid syntax, which violates this rule. Not that I personally could tell you why the parser makes a distinction here, but it's at least part of the reason :)

  irb(main):010:0> foo {a: "b"}
  SyntaxError: (irb):10: syntax error, unexpected ':', expecting '}'
  foo {a: "b"}
       ^
  (irb):10: syntax error, unexpected '}', expecting end-of- input
  foo {a: "b"}
            ^
   from /Users/bhuga/.rbenv/versions/2.4/bin/irb:11:in `'
  irb(main):011:0> foo {params(a: "b")}
  NoMethodError: undefined method `foo' for main:Object
   from (irb):11
   from /Users/bhuga/.rbenv/versions/2.4/bin/irb:11:in `'
  irb(main):012:0>
The `sig` syntax has gone through multiple iterations; within the boundaries of Ruby syntax this is the best we've had.

Re: Types will be part of Ruby 3 stdlib source

#93

Post by sametmax »

zmmmmm wrote: post #81

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…

I get what you mean, but dynamic typing is a feature, just like static typing is.

Some languages are better from a static POV, and offer some auto features. Some languages are better from a dynamic POV and offer some hinting feature.

You don't want to type your code to do data exploration and analysis, but you may want to extend the original project later to something bigger and move on to types.

There is no such thing as the perfect language for everything anyway. Plus, it's very good that some languages integrates unnatural features to them, for the case where you want to go beyond their initial best case scenario. It won't be perfect, but I don't need perfect, I need programmatic.

The world of programming is vast, the pool of programmers very heterogeneous, and the constraints are super diverse.

Re: Types will be part of Ruby 3 stdlib source

#94

Post by pjmlp »

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…

> I was once told "when your try improving a programming language performance, it eventually turns into C"

Which is kind of ironic given how bad C compilers generated code during the mid-80s, versus other mainframe languages.

Re: Types will be part of Ruby 3 stdlib source

#95

Post by technion »

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?

Re: Types will be part of Ruby 3 stdlib source

#96

Post by readittwice »

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…

Well I am skeptical about performance improvements due to type annotations as well. Other languages have similar different systems and didn't get faster.

Dart had gradual types but didn't enforce them at runtime because of performance. The PyPy devs don't believe that type annotations help them for performance (http://doc.pypy.org/en/latest/faq.html#would-type-annotation...). Also there is no JS engine that uses TypeScript annotations so far to improve performance.

Types are usually on the wrong boundary: e.g. Integer doesn't state whether that value fits into a register or is a Bignum.

Also: Aren't some type checks quite expensive? So more expensive than a simple map/class/shape check? E.g. passing an array from untyped code to a signature with something like `Array`. Wouldn't a runtime that verifies signatures have to check all elements in the array to be actual Integers?

Re: Types will be part of Ruby 3 stdlib source

#97

Post by geraldbauer »

cutler wrote: post #83

Instead of: sig {params(name: String).returns(Integer)} ... why not simply: sig {name: String, returns: Integer}

Instead of:

   sig {params(name: String).returns(Integer)}
... why not simply:

   sig [String]=>[Integer]
Yes, that's just ruby - see https://github.com/s6ruby/ruby-to-michelson/blob/master/cont... for example for live running code (in secure ruby) :-)

Re: Types will be part of Ruby 3 stdlib source

#98

Post by DCoder »

black-alert wrote: post #58
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.

I come from Assembly and C, now working in Javascript. One of the reasons I made the move to JS is dynamic typing, getting rid of that administrative pain and now being able to create stuff much faster. Even in large JS apps I hardly ever have type related bugs at all, and when I have one I fix it mostly within minutes, don't need an entirely different language and ecosystem for that. Now the JS fanboys discovered an…

I started using TypeScript back when it was 0.8, before it even had generics. Does that make me a fanboy? I have a project with about 45k SLOC of TypeScript (using Knockout.js for presentation). There is really no way I would maintain that same project without types.

> For my work I look at horrible code bases, perfectly typed and strictly formatted by tslint.

There is no language that can stop people from producing horrible code.

Re: Types will be part of Ruby 3 stdlib source

#99

Post by cutler »

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.

Re: Types will be part of Ruby 3 stdlib source

#100

Post by mnarayan01 »

bhuga wrote: post #92
cutler wrote: post #83

Instead of: sig {params(name: String).returns(Integer)} ... why not simply: sig {name: String, returns: Integer}

Ruby itself has zero changes from sorbet, so all sorbet syntax has to be valid Ruby. `sig` is implemented as a library. In this case, your example is not valid syntax, which violates this rule. Not that I personally could tell you why the parser makes a distinction here, but it's at least part of the reason :) irb(main):010:0> foo {a: "b"} SyntaxError: (irb):10: syntax error, unexpected ':', expecting '}' foo {a: "b"…

The parser thinks that's a block not a hash.
Post reply on HN