15 ms·

Types will be part of Ruby 3 stdlib source

387 points by darkdimius 7y ago

auvi 7y ago
when Ruby 3.0 will be released? 2022 Christmas?
- rajangdavis 7y ago
  2019?
  - lloeki 7y ago
    2019 is 2.7. GP is counting as if version numbers were decimals (2.8 in 2020, 2.9 in 2021, 3.0 in 2022 when it could just as well be 2.10)
- arnvald 7y ago
  Not necessarily. There are certain things the core team wants to add to Ruby 3.0 and once all goals are reached, the next release will be called 3.0 (so we might possibly see Ruby 2.8, 2.9, 2.10 etc before). The earliest possible date (and somewhere I read it's a probable one, but I can't find it right now) is Christmas 2020.
rarrrrr 7y ago
Nice! Reminds me of crystal[0], the LLVM-compiled ruby-alike language. 0: https://crystal-lang.org https://crystal-lang.org
- leshow 7y ago
  Except crystal's type system seems much more capable & powerful.
inopinatus 7y ago
It looks like they've conflated type with class. If so, that's the antithesis of duck typing. The impedence mismatch to Ruby seems to me an overwhelming contraindication.
- pmontra 7y ago
  Do you have any reference to any documentation of how they implemented types?
  - inopinatus 7y ago
    The docs say "Every Ruby class and module doubles as a type in Sorbet" and it was explicitly described as a nominal type system in a talk at Strange Loop 2018.
- masklinn 7y ago
  > It looks like they've conflated type with class. Classes are types by default, but you can define non-class types as well: https://sorbet.org/docs/abstract https://sorbet.org/docs/abstract
- coldtea 7y ago
  Well, classes are types in a language where everything is an object. It's the same in Smalltalk, no?
  - inopinatus 7y ago
    That is exactly the category error I am calling out. In a duck-typed language, type is defined by the willingness of a message receiver to receive that message. Class, inheritance, composition are all means to achieve this, but the type of an object is determined by its signature, not its ancestor chain.
- quelltext 7y ago
  Not sure you can call yjis conflation. From what I've read that was a deliberate thought out decision and a nominal type system is as valid a choice as a structural one and generally better understood in research and industry. Having said that as far as I understand, type support in Ruby 3 will not prescribe which type checker is used and what limitations exist. Some of the mentioned projects are structural and I think even Sorbet might add support for it at some point.
- 7y ago
_hardwaregeek 7y ago
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 seeing how the Ruby team designs the type system. It'll be gradual, of course, but also it'll be interesting what adaptations they'll have to make to accommodate existing code. JavaScript relied on a lot of stringly typed code, so TypeScript added string literal types. Perhaps Ruby's dynamic, block oriented style could lead to some interesting decisions in the type system. Not to mention, the types will most likely be reified as per Ruby's philosophy. Super excited for this. Between the JIT and types, Ruby could definitely see a renaissance in the near future.
- darkdimius 7y ago
  Indeed Sorbet does have literal types for strings and Ruby symbols. We're still figuring out the details and converging on a common type system for Ruby3, but we've found them super useful, as you rightly point out! And +1 on the Ruby renaissance! Super excited about all the exciting things that are currently being built!
  - _hardwaregeek 7y ago
    I can't wait for Sorbet's open sourcing! Ngl I tried decompiling the wasm binary just for fun. Not that it ended up being readable haha
    - darkdimius 7y ago
      We're currently looking for beta users! Reach out to us at sorbet@stripe.com. If you describe your team&codebase in the email, it will help us figure out what cohort to include you in.
- baybal2 7y ago
  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?
phaedryx 7y ago
I recommend whatching "Ruby3: What's Missing?", a presentation Matz gave earlier this month: https://www.youtube.com/watch?v=cmOt9HhszCI 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.
- aasasd 7y ago
  As a user of Homebrew, I just wonder if Ruby's ever going to have performance.
  - theredbox 7y ago
    Yes and no. You need to basically fork the compiler and invent a new type of ruby that sacrifices certain things in favor of performance.
  - bjoli 7y ago
    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.
    - aasasd 7y ago
      > It is no worse than python Eeeeeeeh…
      - bjoli 7y ago
        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.
        aasasd 7y ago
        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.
didibus 7y ago
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.
- xvilka 7y ago
  Why not a standard Common Lisp istead? Or even Scheme/Racket?
  - didibus 7y ago
    Well, I'm not seeing as much activity on CL. But for me, it's mostly a practical reason. I can easily use Clojure or sprinkle some around in most enterprise context because it runs in a symbiosis with existing platforms like the JVM, the CLR, and the various Javascript VMs. So it's much more usable in my day to day. I also feel that CL and Racket have embraced types a lot more. Doesn't CL have a fair bit of static typing already? And with Racket, Typed Racket has pretty much pioneered the concept of gradual typing now being applied to JS, Python and Ruby. I know Racket also explored contracts, and has a lot of great ideas. But I feel overall it's missing the: "and we dog food it all on real business use cases in production" aspect that Clojure has. And for CL, it doesn't seem to have as much in terms of contracts, data DSLs, immutability, simpler primitives, etc. It feels more like a traditional mutable, OOP, dynamic language. It has nailed down the interactive development part though. I don't want to put it down as I'm interested to try more of CL, but overall, it just doesn't seem as active or opinionated anymore. If anything, CL seems to lack any form of opinion, and goes more for the: we just add all features of every other language. Which is a quality on its own, but not driving the discussions forward either.
    - Jach 7y ago
      CL has static typing and such in at least three important senses that aren't usually called out explicitly in these discussions. First, you can annotate types and some compilers (notably the popular SBCL) can warn you, at compile time, about issues around using the wrong types, undefined vars, unused vars, wrong arguments passed to function, etc. I've read somewhere that's all based on Kaplan-Ullman type inference developed in the '80s, along with an example implementation for CL: http://home.pipeline.com/~hbaker1/TInference.html http://home.pipeline.com/~hbaker1/TInference.html This is the sense of using types to help you write more correct software. It's obviously not as rigorous as Java/Haskell/Shen and not everything can be done at compile time. On the other hand CL has very flexible type definitions, so you get possibilities like "integers 2,3,4,5" as a type rather than limited to "all integers" or custom types like "is keyword :a or :b or :c". Second, compilers can use type information (or inlining hints, etc.) to compile efficient machine code, which you can inspect with the built-in function 'DISASSEMBLE. Third, types are used in the CLOS system to support efficient multiple dispatch for multimethods, and the rest of the CLOS and MOP machinery that makes it a very "non-traditional" (despite CLOS being first to ANSI standardize) OOP system with a lot more power than other fashionable languages provide. I'm basically in agreement with the title of http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end http://www.smashcompany.com/technology/object-oriented-progr... with the caveats that Lisp is different and an exception (even if not perfect, there's an unfortunate mismatch in methods not allowing any type for dispatching on, though you can work around it in a similar fashion to Clojure's multimethods of dispatching on a runtime value) and that carefully designed Java can make the forced OOP tolerable. CL is also super dynamic and lets you redefine basically everything so none of this is truly "static", and that's why compilers will warn rather than error, and runtimes while developing will preserve your state and drop you in a debugger instead of destroying state, printing a stacktrace, and giving up, because you can fix it and recompile that little bit or rerun after defining a missing variable. CL's conditions and restarts system has yet to be convincingly cloned by other languages. Contracts, DSLs, immutable data structures, simple primitives, and other things (some not present in any other languages) are available in CL... My own reading has found that a lot of them have been there or in the predecessors to the CL standardization or in things built on top since for a long time (some well before I was born) and explored by big production business applications, not just academic exercises... Some of course are more modern transplants as they haven't gotten popular until recently. But for the things that were there already, in a sense the discussions have already been done and may help explain the lack of driving force for them now. In other languages I see them driving themselves close to where CL already is more often than driving to a completely new place (but then CL provides and lets you go there too, or at least somewhere close). You're free to use these things in CL, or not; you're right that it's not an opinionated language and I'd argue never was. Fortunately there's enough capability for modularization that we can have different opinions (e.g. the meaning of syntax like [Click me] in a UI component) and still trivially share code. It's a shame that Clojure code and CL code can't be trivially shared.
kenneth 7y ago
This is HUGE! Ruby's pace of development continues to impress. It's always been an impressively practical language and keeps getting better.
cocochanel 7y ago
Why is everything moving to types?
- symlinkk 7y ago
  Because TypeScript has proven that a type system can be helpful without being clunky and annoying.
  - eru 7y ago
    I thought the ML family of languages showed that long ago? I guess TypeScript popularized the notion.
    - bfung 7y ago
      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 - try 3 * "3"). This leads to a whole class of bugs not possible in a statically typed codebase where explicit conversion needs to happen - I have no hard data, but I remember debugging this type of stuff far too often and far too many times when I could've spend my time better elsewhere. (but I actually like ruby a lot!) Type checking is not the same as being statically vs. dynamically typed!
      - abhorrence 7y ago
        > a variable holding a 1 can turn into a "1" and back This is true of Javascript, but not of Ruby. irb(main):001:)> 3 * "3" TypeError: String can't be coerced into Fixnum People commonly conflate dynamic typing with weak typing, Ruby has the former, but not the latter (with some explicit exceptions, e.g. to_ary and friends). That's not to say you can't still end up with some interesting problems though -- if we just slightly change your example: a = 3 b = 3 # later... a = "oops" product = a * b # product is now "oopsoopsoops" But this isn't due to automatic "weak types" style coercion -- just that Ruby lets you build a repeated string by multiplying a string by a number.
darkdimius 7y ago
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 https://youtu.be/cmOt9HhszCI?t=2148
- pmontra 7y ago
  So, something along the lines of https://github.com/soutaro/steep 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.
- mratzloff 7y ago
  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 through third-party code trying to figure out what certain parameters were supposed to be than writing the program itself.
  - uryga 7y ago
    i haven't used it, but have you looked at the Crystal language? i think the idea is basically "statically typed Ruby".
    - mratzloff 7y ago
      I've heard of it and looked at it a bit, but haven't had a chance to use it yet!
  - fouc 7y ago
    Could elixir be a good alternative? It has typespecs https://elixir-lang.org/getting-started/typespecs-and-behaviours.html https://elixir-lang.org/getting-started/typespecs-and-behavi...
jaequery 7y ago
Types will be optional right? Otherwise I am gonna have to jump ship sadly.
- darkdimius 7y ago
  See https://news.ycombinator.com/item?id=19697581 https://news.ycombinator.com/item?id=19697581
b123400 7y ago
Interesting. I thought the Ruby community generally prefers shorter code, e.g. `to_s` instead of `to_string`, and yet that type signature is very verbose: `sig {params(x: Integer).returns(String)}`
- lloeki 7y ago
  Integer and String are the actual classes: “foo”.class # => String
- deleted 7y ago
  [deleted]
- geraldbauer 7y ago
  The type signature in (secure) ruby [1] - an alternative ruby (subset) with type (optional) annotation - is `sig Integer => String` or `sig [Integer] => [String]. Since the sig is just ruby you can create an alias for types e.g. I = Integer, S = String and than use sig I=>S, for example. [1]: https://github.com/s6ruby https://github.com/s6ruby
joelbluminator 7y ago
My concern about all of this is that it might lead to basically two ruby communities; Rails and Rails devs will mostly keep writing type free code (dhh has always indicated he's not a fan of types), but a lot of other rubyists will gradually introduce types into their code. This could create two different ecosystems with different gems, best practices, blogs etc etc etc. We will see how it plays out but I'm quite conflicted about this one. The good thing is that it's optional.
- DyslexicAtheist 7y ago
  perl6 and python3 were my first thought. I think this is great though, but maybe they should change the naming of this new version completely so that they can make a clean cut. Rather have less backward compatibility and clean design as opposed to forcing a square peg in a round hole
- jez 7y ago
  It’s not in the tweet but we specifically covered that it’s possible to type check Rails in our talk actually: - https://sorbet.run/talks/RubyKaigi2019/#/53 https://sorbet.run/talks/RubyKaigi2019/#/53 - https://sorbet.run/talks/RubyKaigi2019/#/55 https://sorbet.run/talks/RubyKaigi2019/#/55 So I don’t think that the divide will be at Rails. And more than that, I think there will be very little divide at all. Sorbet is designed to be gradual, so it works 100% fine with untyped code: https://sorbet.org/docs/gradual https://sorbet.org/docs/gradual
  - joelbluminator 7y ago
    Hi thanks for this! Could you shed more light on the last part where they show parts of Rails, Gitlab etc are already typed? How is this possible?
    - z1mm32m4n 7y ago
      Sorbet has multiple Strictness Levels[1]. The two most relevant ones are `typed: false` and `typed: true`. `typed: false` is the default level and at this level only errors related to constants are reported, like this one: https://sorbet.run/talks/RubyKaigi2019/#/14 https://sorbet.run/talks/RubyKaigi2019/#/14 But we'd like to catch more than just errors related to constants, like those related to missing methods, or calling a method with the wrong arguments. Errors like these are only reported in files marked `typed: true`: https://sorbet.run/talks/RubyKaigi2019/#/19 https://sorbet.run/talks/RubyKaigi2019/#/19 Sorbet doesn't need to have method signatures to know whether a method exists at all, or what arity that method has. But more than that, Sorbet ships with type definitions for the standard library. So you don't even need to start annotating your methods to type check the body of your methods, because most of the body of your methods are calling standard library things (arrays, hashes, map, each, etc.). The statistics in those slides are sharing "out of the box, what's the highest strictness level that could be added to a file without introducing errors?" So ideally an entire project be made `typed: true`, but Sorbet can be adopted gradually, so a project can exist in a partial state of typedness. We wanted to see how painful it would be to adopt Sorbet in a handful of large, open source rails projects, and it turned out to be not that bad. [1]: https://sorbet.org/docs/static#file-level-granularity-strictness-levels https://sorbet.org/docs/static#file-level-granularity-strict...
geraldbauer 7y ago
FYI: For an alternative ruby (subset) with type annotations today see sruby, that is, secure ruby - https://github.com/s6ruby https://github.com/s6ruby
geraldbauer 7y ago
FYI: You can add the missing Bool type today :-), use the safebool library / gem - https://github.com/s6ruby/safebool https://github.com/s6ruby/safebool
- Dirlewanger 7y ago
  Are TrueClass/FalseClass being united under one class for 3?
deleted 7y ago
[deleted]
sunasra 7y ago
This is super cool. I would expect the same support for Rails after Ruby 3 release
snrji 7y ago
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.
- Guthur 7y ago
  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.
  - jmkni 7y ago
    You could argue that something that has been around for decades is unstoppable :)
  - snrji 7y ago
    It was not mainstream back then. I agree that most popular dynamic are quite terrible. But, honestly, I think the real problem is not the particular implementations, but the whole idea of dynamic typing. At first it did make sense, but now that compiler writers have figured out "cheap" and general type inference, I don't see the point anymore. However, I use Python on a daily basis because I have no decent alternative for the libraries I use.
tosh 7y ago
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 tend to no longer feel like dynamically typed languages as the annotations and the tooling spreads and spreads and spreads. Not easy to put up boundaries.
- IshKebab 7y ago
  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...
- cageface 7y ago
  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.
  - rmsaksida 7y ago
    Agreed. Unsurprisingly a lot of libraries are being rewritten in TS, including some high profile ones. I've been writing JS for a decade and TypeScript was a game changer for me.
  - techsin101 7y ago
    Tell me few .. to me types were useful for hinting in ide but vscode already gives good hints
    - simplify 7y ago
      Types are not just for autocompleting, but also for making illegal states unrepresentable[0]. For example, let's say you have Question model with two types: MultipleChoice and ShortAnswer. In TypeScript you can model it like this: type MultipleChoice = { mode: 'mc' body: string choices: string[] expectedAnswer: number } type ShortAnswer = { mode: 'sa' body: string exampleAnswer: string } type Question = MultipleChoice | ShortAnswer TypeScript's compiler will then enforce data structure consistency across your entire codebase. For example, if you were rendering a question in React: type Props = { question: Question } const MyComponent = (props: Props) => { props.question.body // Ok, since all questions have a body props.question.choices // Type error, since only MC has choices if (props.question.mode === 'mc') { props.question.choices // Ok now, since we checked the mode of question } } You can also use these types to force certain code to always be correct. For example, if you wanted to display a human-readable version of a Question's mode, you could write: const prettyQuestionType: Record<Question["mode"], string> = { mc: 'Multiple Choice', sa: 'Short Answer', } and now TypeScript will force prettyQuestionType to contain keys for all modes. That includes when you add a new Question mode later. Once you learn how to lean on the type checker, you think less about such details, and your mind becomes freer to think at a higher level, increasing your overall productivity. There is a learning curve though, so be aware. [0] https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/ https://fsharpforfunandprofit.com/posts/designing-with-types...
carmate383 7y ago
Ah yes, a last ditch effort to claw back an inferior language into the popularity again. This is nothing more than a knee-jerk reaction to loss of market-share to TypeScript / Python / Name your other buzz-language here (R)
- cutler 7y ago
  Ruby inferior to Javascript and Python? What are you smoking? Python's BDFL begrudgingly added lambda to Python but amputated it to single-line expressions because he didn't want to "encourage" functional programming. By contrast Ruby is an artistically-curated blend of the best of Smalltalk, Lisp and Perl fully embracing functional programming. No contest.
ricardobeat 7y ago
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/ https://crystal-lang.org/
- cyberferret 7y ago
  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.
- technion 7y ago
  Why should the people who built and maintain Ruby focus their efforts on a different language?
  - ricardobeat 7y ago
    You can ask the creator himself: https://github.com/mruby/mruby https://github.com/mruby/mruby
- imhoguy 7y ago
  Because it is about Rails and tons of useful gems which would need to be ported 1:1 to Crystal, plus keep compatibility with CRuby for some time. Too much effort which nobody would pay for.
zmmmmm 7y ago
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.
- hrktb 7y ago
  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.
- sametmax 7y ago
  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.
  - paganel 7y ago
    > There is no such thing as the perfect language for everything anyway. People tend to forget this all to easily. For example most of the static type discussions for the past 10 years have taken place on a website built in a dynamic programming language, I'm talking about http://lambda-the-ultimate.org/ http://lambda-the-ultimate.org/ which afaik is built in Drupal (i.e. PHP).
cutler 7y ago
Instead of: sig {params(name: String).returns(Integer)} ... why not simply: sig {name: String, returns: Integer}
- tomstuart 7y ago
  How would you write the type of a function that takes a parameter called `returns`?
  - cutler 7y ago
    Simple - make 'returns' a reserved word.
- deleted 7y ago
  [deleted]
- bhuga 7y ago
  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 `<main>' 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 `<main>' 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.
  - mnarayan01 7y ago
    The parser thinks that's a block not a hash.
    - cutler 7y ago
cutler 7y ago
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.
- adimitrov 7y ago
  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 Haskell style to always annotate the type sigs of top-level functions. Why? Because they serve as more than just hints to the compiler: they are part (and a very important part!) of the documentation. That is why they're in-line. Because A function like zipWith:: [a] -> [b] -> (a -> b -> c) -> [c] tells you what it does in its type signature.
  - cutler 7y ago
    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.
    - Faark 7y ago
      > 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.
      - mcintyre1994 7y ago
        It's been a while since I wrote Ocaml, but IIRC the compiler yells at you if your mli files are out-of-date, for whatever that's worth. So keeping them synced isn't really an issue.
localhostdotdev 7y ago
small discussion that was marked as dupe https://news.ycombinator.com/item?id=19696669 https://news.ycombinator.com/item?id=19696669
fulafel 7y ago
Ruby already had types, no? This is about static typing.
- cies 7y ago
  My thought too. Interesting what the definition of "static" will turn out to be in the context of something so inherently dynamic as Ruby.
- viraptor 7y ago
  If you're going for precision, then probably: type-annotations. The runtime doesn't change with sorbet. All the verification is via an external tool. So there's no static typing - your code can still violate the rules.
vemv 7y ago
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.
- steveklabnik 7y ago
  From the slides that are linked in the tweet in the tweet: https://sorbet.run/talks/RubyKaigi2019/#/45 https://sorbet.run/talks/RubyKaigi2019/#/45
gigatexal 7y ago
I hope Python 4 goes this route.
rswillif 7y ago
All of these beneficial refinements are meaningless if increasing performance optimization in the runtime isn't made more of a priority.
vemv 7y ago
Learning from the clojure.spec success story, what might make/break Sorbet is its runtime capabilities, aka reification. * Can I emit typed REST API docs out of sorbet types? * Can I coerce HTTP params out of sorbet types? * Can I emit ActiveRecord columns? ActiveModel validations? * Can I emit generative tests? You can do all of those (and whatever else you imagine) with clojure.spec in a DRY manner, i.e. types are defined once, and reused in a variety of contexts. As a Rails dev, I would greatly value all of those, particularly because they're practical things directly related to my webdev activity. Ensuring the type safety of the codebase is great, but also implicitly exercised by an adequate test suite.
ekvintroj 7y ago
There is something similar (but more powerful) for Smalltalk, it collects the types as you run the code and then it is used to improve the refactors. Check it out. https://github.com/hernanwilkinson/LiveTyping https://github.com/hernanwilkinson/LiveTyping
virtualwhys 7y ago
Great for Ruby (OP was arguably the most important compiler dev behind Martin Odersky on the Dotty/Scala 3 project), types for the win.
geraldbauer 7y ago
FYI: The RubyKaigi 2019 Progress Report on Ruby 3 Talk Slides have more (from the source) info. See the slides titled "Static Analysis" [1] Ruby 3 static analysis will have four items: 1. Type signature format 2. Level-1 type checking tool 3. Type signature profiling / prototyping tool 4. Level-2 type checking tools and so on. [1]: https://docs.google.com/presentation/d/1z_5JT0-MJySGn6UGrtdafK1oj9kGSO5sGlTtEQJz0JU/view#slide=id.g57cf166414_14_5 https://docs.google.com/presentation/d/1z_5JT0-MJySGn6UGrtda...
gkemmey 7y ago
Why do these efforts have to move into Ruby proper? Why can't sorbet or steep stay their own thing, and if it solves your Stripe-like-codebase problems, great. What I don't see a lot of here (or in general these days) is advocacy for the advantages of dynamic typing. And if you're objective, there most certainly are, even if they're not worth the disadvantages, or don't surpass the advantages of static typing for you, personally. But Ruby used to advocate for them, and it's definitely what drew me in. I find it disappointing that we're moving away from that. More and more, it seems we’re attempting to make Ruby all things to all people. Which eventually makes it the right thing for no one.
- detaro 7y ago
  How do optional typing annotations break ruby/Python/... for you?
  - gkemmey 7y ago
    Well, I think there's a bit of mandatory-ness that comes with adding it to Ruby itself. Sounds like the standard library is going to ship with rbi files defined, for instance. Plus, tools for generating rbi files. On some level, it's an endorsement to do things this way, right? And that's before it (potentially) becomes a community practice to do so. If it's not, why not leave these solutions in gems? Btw, I don't think static typing alone is Ruby becoming all things to all people. In recent history, it's also aliasing `Enumerable#filter` to `Enumerable#select`, numbered block arguments, a shorthand special notation for `Object#method` -- it feels like a trend of "hey these other languages do this, we should too". I'm not convinced that's always the case.

387 points by darkdimius 7y ago

auvi 7y ago

when Ruby 3.0 will be released? 2022 Christmas?

rajangdavis 7y ago
2019?
- lloeki 7y ago
  2019 is 2.7. GP is counting as if version numbers were decimals (2.8 in 2020, 2.9 in 2021, 3.0 in 2022 when it could just as well be 2.10)
arnvald 7y ago
Not necessarily. There are certain things the core team wants to add to Ruby 3.0 and once all goals are reached, the next release will be called 3.0 (so we might possibly see Ruby 2.8, 2.9, 2.10 etc before). The earliest possible date (and somewhere I read it's a probable one, but I can't find it right now) is Christmas 2020.

rarrrrr 7y ago

Nice! Reminds me of crystal[0], the LLVM-compiled ruby-alike language. 0: https://crystal-lang.org https://crystal-lang.org

leshow 7y ago
Except crystal's type system seems much more capable & powerful.

inopinatus 7y ago

It looks like they've conflated type with class. If so, that's the antithesis of duck typing. The impedence mismatch to Ruby seems to me an overwhelming contraindication.

pmontra 7y ago
Do you have any reference to any documentation of how they implemented types?
- inopinatus 7y ago
  The docs say "Every Ruby class and module doubles as a type in Sorbet" and it was explicitly described as a nominal type system in a talk at Strange Loop 2018.
masklinn 7y ago
> It looks like they've conflated type with class. Classes are types by default, but you can define non-class types as well: https://sorbet.org/docs/abstract https://sorbet.org/docs/abstract
coldtea 7y ago
Well, classes are types in a language where everything is an object. It's the same in Smalltalk, no?
- inopinatus 7y ago
  That is exactly the category error I am calling out. In a duck-typed language, type is defined by the willingness of a message receiver to receive that message. Class, inheritance, composition are all means to achieve this, but the type of an object is determined by its signature, not its ancestor chain.
quelltext 7y ago
Not sure you can call yjis conflation. From what I've read that was a deliberate thought out decision and a nominal type system is as valid a choice as a structural one and generally better understood in research and industry. Having said that as far as I understand, type support in Ruby 3 will not prescribe which type checker is used and what limitations exist. Some of the mentioned projects are structural and I think even Sorbet might add support for it at some point.
7y ago

_hardwaregeek 7y ago

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 seeing how the Ruby team designs the type system. It'll be gradual, of course, but also it'll be interesting what adaptations they'll have to make to accommodate existing code. JavaScript relied on a lot of stringly typed code, so TypeScript added string literal types. Perhaps Ruby's dynamic, block oriented style could lead to some interesting decisions in the type system. Not to mention, the types will most likely be reified as per Ruby's philosophy. Super excited for this. Between the JIT and types, Ruby could definitely see a renaissance in the near future.

darkdimius 7y ago
Indeed Sorbet does have literal types for strings and Ruby symbols. We're still figuring out the details and converging on a common type system for Ruby3, but we've found them super useful, as you rightly point out! And +1 on the Ruby renaissance! Super excited about all the exciting things that are currently being built!
- _hardwaregeek 7y ago
  I can't wait for Sorbet's open sourcing! Ngl I tried decompiling the wasm binary just for fun. Not that it ended up being readable haha
  - darkdimius 7y ago
    We're currently looking for beta users! Reach out to us at sorbet@stripe.com. If you describe your team&codebase in the email, it will help us figure out what cohort to include you in.
baybal2 7y ago
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?

phaedryx 7y ago

I recommend whatching "Ruby3: What's Missing?", a presentation Matz gave earlier this month: https://www.youtube.com/watch?v=cmOt9HhszCI 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.

aasasd 7y ago
As a user of Homebrew, I just wonder if Ruby's ever going to have performance.
- theredbox 7y ago
  Yes and no. You need to basically fork the compiler and invent a new type of ruby that sacrifices certain things in favor of performance.
- bjoli 7y ago
  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.
  - aasasd 7y ago
    > It is no worse than python Eeeeeeeh…
    - bjoli 7y ago
      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.
      - aasasd 7y ago
        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.

didibus 7y ago

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.

xvilka 7y ago
Why not a standard Common Lisp istead? Or even Scheme/Racket?
- didibus 7y ago
  Well, I'm not seeing as much activity on CL. But for me, it's mostly a practical reason. I can easily use Clojure or sprinkle some around in most enterprise context because it runs in a symbiosis with existing platforms like the JVM, the CLR, and the various Javascript VMs. So it's much more usable in my day to day. I also feel that CL and Racket have embraced types a lot more. Doesn't CL have a fair bit of static typing already? And with Racket, Typed Racket has pretty much pioneered the concept of gradual typing now being applied to JS, Python and Ruby. I know Racket also explored contracts, and has a lot of great ideas. But I feel overall it's missing the: "and we dog food it all on real business use cases in production" aspect that Clojure has. And for CL, it doesn't seem to have as much in terms of contracts, data DSLs, immutability, simpler primitives, etc. It feels more like a traditional mutable, OOP, dynamic language. It has nailed down the interactive development part though. I don't want to put it down as I'm interested to try more of CL, but overall, it just doesn't seem as active or opinionated anymore. If anything, CL seems to lack any form of opinion, and goes more for the: we just add all features of every other language. Which is a quality on its own, but not driving the discussions forward either.
  - Jach 7y ago
    CL has static typing and such in at least three important senses that aren't usually called out explicitly in these discussions. First, you can annotate types and some compilers (notably the popular SBCL) can warn you, at compile time, about issues around using the wrong types, undefined vars, unused vars, wrong arguments passed to function, etc. I've read somewhere that's all based on Kaplan-Ullman type inference developed in the '80s, along with an example implementation for CL: http://home.pipeline.com/~hbaker1/TInference.html http://home.pipeline.com/~hbaker1/TInference.html This is the sense of using types to help you write more correct software. It's obviously not as rigorous as Java/Haskell/Shen and not everything can be done at compile time. On the other hand CL has very flexible type definitions, so you get possibilities like "integers 2,3,4,5" as a type rather than limited to "all integers" or custom types like "is keyword :a or :b or :c". Second, compilers can use type information (or inlining hints, etc.) to compile efficient machine code, which you can inspect with the built-in function 'DISASSEMBLE. Third, types are used in the CLOS system to support efficient multiple dispatch for multimethods, and the rest of the CLOS and MOP machinery that makes it a very "non-traditional" (despite CLOS being first to ANSI standardize) OOP system with a lot more power than other fashionable languages provide. I'm basically in agreement with the title of http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end http://www.smashcompany.com/technology/object-oriented-progr... with the caveats that Lisp is different and an exception (even if not perfect, there's an unfortunate mismatch in methods not allowing any type for dispatching on, though you can work around it in a similar fashion to Clojure's multimethods of dispatching on a runtime value) and that carefully designed Java can make the forced OOP tolerable. CL is also super dynamic and lets you redefine basically everything so none of this is truly "static", and that's why compilers will warn rather than error, and runtimes while developing will preserve your state and drop you in a debugger instead of destroying state, printing a stacktrace, and giving up, because you can fix it and recompile that little bit or rerun after defining a missing variable. CL's conditions and restarts system has yet to be convincingly cloned by other languages. Contracts, DSLs, immutable data structures, simple primitives, and other things (some not present in any other languages) are available in CL... My own reading has found that a lot of them have been there or in the predecessors to the CL standardization or in things built on top since for a long time (some well before I was born) and explored by big production business applications, not just academic exercises... Some of course are more modern transplants as they haven't gotten popular until recently. But for the things that were there already, in a sense the discussions have already been done and may help explain the lack of driving force for them now. In other languages I see them driving themselves close to where CL already is more often than driving to a completely new place (but then CL provides and lets you go there too, or at least somewhere close). You're free to use these things in CL, or not; you're right that it's not an opinionated language and I'd argue never was. Fortunately there's enough capability for modularization that we can have different opinions (e.g. the meaning of syntax like [Click me] in a UI component) and still trivially share code. It's a shame that Clojure code and CL code can't be trivially shared.

kenneth 7y ago

This is HUGE! Ruby's pace of development continues to impress. It's always been an impressively practical language and keeps getting better.

cocochanel 7y ago

Why is everything moving to types?

symlinkk 7y ago
Because TypeScript has proven that a type system can be helpful without being clunky and annoying.
- eru 7y ago
  I thought the ML family of languages showed that long ago? I guess TypeScript popularized the notion.
  - bfung 7y ago
    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 - try 3 * "3"). This leads to a whole class of bugs not possible in a statically typed codebase where explicit conversion needs to happen - I have no hard data, but I remember debugging this type of stuff far too often and far too many times when I could've spend my time better elsewhere. (but I actually like ruby a lot!) Type checking is not the same as being statically vs. dynamically typed!
    - abhorrence 7y ago
      > a variable holding a 1 can turn into a "1" and back This is true of Javascript, but not of Ruby. irb(main):001:)> 3 * "3" TypeError: String can't be coerced into Fixnum People commonly conflate dynamic typing with weak typing, Ruby has the former, but not the latter (with some explicit exceptions, e.g. to_ary and friends). That's not to say you can't still end up with some interesting problems though -- if we just slightly change your example: a = 3 b = 3 # later... a = "oops" product = a * b # product is now "oopsoopsoops" But this isn't due to automatic "weak types" style coercion -- just that Ruby lets you build a repeated string by multiplying a string by a number.

darkdimius 7y ago

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 https://youtu.be/cmOt9HhszCI?t=2148

pmontra 7y ago
So, something along the lines of https://github.com/soutaro/steep 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.
mratzloff 7y ago
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 through third-party code trying to figure out what certain parameters were supposed to be than writing the program itself.
- uryga 7y ago
  i haven't used it, but have you looked at the Crystal language? i think the idea is basically "statically typed Ruby".
  - mratzloff 7y ago
    I've heard of it and looked at it a bit, but haven't had a chance to use it yet!
- fouc 7y ago
  Could elixir be a good alternative? It has typespecs https://elixir-lang.org/getting-started/typespecs-and-behaviours.html https://elixir-lang.org/getting-started/typespecs-and-behavi...

jaequery 7y ago

Types will be optional right? Otherwise I am gonna have to jump ship sadly.

darkdimius 7y ago
See https://news.ycombinator.com/item?id=19697581 https://news.ycombinator.com/item?id=19697581

b123400 7y ago

Interesting. I thought the Ruby community generally prefers shorter code, e.g. `to_s` instead of `to_string`, and yet that type signature is very verbose: `sig {params(x: Integer).returns(String)}`

lloeki 7y ago
Integer and String are the actual classes: “foo”.class # => String
deleted 7y ago
[deleted]
geraldbauer 7y ago
The type signature in (secure) ruby [1] - an alternative ruby (subset) with type (optional) annotation - is `sig Integer => String` or `sig [Integer] => [String]. Since the sig is just ruby you can create an alias for types e.g. I = Integer, S = String and than use sig I=>S, for example. [1]: https://github.com/s6ruby https://github.com/s6ruby

joelbluminator 7y ago

My concern about all of this is that it might lead to basically two ruby communities; Rails and Rails devs will mostly keep writing type free code (dhh has always indicated he's not a fan of types), but a lot of other rubyists will gradually introduce types into their code. This could create two different ecosystems with different gems, best practices, blogs etc etc etc. We will see how it plays out but I'm quite conflicted about this one. The good thing is that it's optional.

DyslexicAtheist 7y ago
perl6 and python3 were my first thought. I think this is great though, but maybe they should change the naming of this new version completely so that they can make a clean cut. Rather have less backward compatibility and clean design as opposed to forcing a square peg in a round hole
jez 7y ago
It’s not in the tweet but we specifically covered that it’s possible to type check Rails in our talk actually: - https://sorbet.run/talks/RubyKaigi2019/#/53 https://sorbet.run/talks/RubyKaigi2019/#/53 - https://sorbet.run/talks/RubyKaigi2019/#/55 https://sorbet.run/talks/RubyKaigi2019/#/55 So I don’t think that the divide will be at Rails. And more than that, I think there will be very little divide at all. Sorbet is designed to be gradual, so it works 100% fine with untyped code: https://sorbet.org/docs/gradual https://sorbet.org/docs/gradual
- joelbluminator 7y ago
  Hi thanks for this! Could you shed more light on the last part where they show parts of Rails, Gitlab etc are already typed? How is this possible?
  - z1mm32m4n 7y ago
    Sorbet has multiple Strictness Levels[1]. The two most relevant ones are `typed: false` and `typed: true`. `typed: false` is the default level and at this level only errors related to constants are reported, like this one: https://sorbet.run/talks/RubyKaigi2019/#/14 https://sorbet.run/talks/RubyKaigi2019/#/14 But we'd like to catch more than just errors related to constants, like those related to missing methods, or calling a method with the wrong arguments. Errors like these are only reported in files marked `typed: true`: https://sorbet.run/talks/RubyKaigi2019/#/19 https://sorbet.run/talks/RubyKaigi2019/#/19 Sorbet doesn't need to have method signatures to know whether a method exists at all, or what arity that method has. But more than that, Sorbet ships with type definitions for the standard library. So you don't even need to start annotating your methods to type check the body of your methods, because most of the body of your methods are calling standard library things (arrays, hashes, map, each, etc.). The statistics in those slides are sharing "out of the box, what's the highest strictness level that could be added to a file without introducing errors?" So ideally an entire project be made `typed: true`, but Sorbet can be adopted gradually, so a project can exist in a partial state of typedness. We wanted to see how painful it would be to adopt Sorbet in a handful of large, open source rails projects, and it turned out to be not that bad. [1]: https://sorbet.org/docs/static#file-level-granularity-strictness-levels https://sorbet.org/docs/static#file-level-granularity-strict...

geraldbauer 7y ago

FYI: For an alternative ruby (subset) with type annotations today see sruby, that is, secure ruby - https://github.com/s6ruby https://github.com/s6ruby

geraldbauer 7y ago

FYI: You can add the missing Bool type today :-), use the safebool library / gem - https://github.com/s6ruby/safebool https://github.com/s6ruby/safebool

Dirlewanger 7y ago
Are TrueClass/FalseClass being united under one class for 3?

deleted 7y ago

[deleted]

sunasra 7y ago

This is super cool. I would expect the same support for Rails after Ruby 3 release

snrji 7y ago

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.

Guthur 7y ago
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.
- jmkni 7y ago
  You could argue that something that has been around for decades is unstoppable :)
- snrji 7y ago
  It was not mainstream back then. I agree that most popular dynamic are quite terrible. But, honestly, I think the real problem is not the particular implementations, but the whole idea of dynamic typing. At first it did make sense, but now that compiler writers have figured out "cheap" and general type inference, I don't see the point anymore. However, I use Python on a daily basis because I have no decent alternative for the libraries I use.

tosh 7y ago

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 tend to no longer feel like dynamically typed languages as the annotations and the tooling spreads and spreads and spreads. Not easy to put up boundaries.

IshKebab 7y ago
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...
cageface 7y ago
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.
- rmsaksida 7y ago
  Agreed. Unsurprisingly a lot of libraries are being rewritten in TS, including some high profile ones. I've been writing JS for a decade and TypeScript was a game changer for me.
- techsin101 7y ago
  Tell me few .. to me types were useful for hinting in ide but vscode already gives good hints
  - simplify 7y ago
    Types are not just for autocompleting, but also for making illegal states unrepresentable[0]. For example, let's say you have Question model with two types: MultipleChoice and ShortAnswer. In TypeScript you can model it like this: type MultipleChoice = { mode: 'mc' body: string choices: string[] expectedAnswer: number } type ShortAnswer = { mode: 'sa' body: string exampleAnswer: string } type Question = MultipleChoice | ShortAnswer TypeScript's compiler will then enforce data structure consistency across your entire codebase. For example, if you were rendering a question in React: type Props = { question: Question } const MyComponent = (props: Props) => { props.question.body // Ok, since all questions have a body props.question.choices // Type error, since only MC has choices if (props.question.mode === 'mc') { props.question.choices // Ok now, since we checked the mode of question } } You can also use these types to force certain code to always be correct. For example, if you wanted to display a human-readable version of a Question's mode, you could write: const prettyQuestionType: Record<Question["mode"], string> = { mc: 'Multiple Choice', sa: 'Short Answer', } and now TypeScript will force prettyQuestionType to contain keys for all modes. That includes when you add a new Question mode later. Once you learn how to lean on the type checker, you think less about such details, and your mind becomes freer to think at a higher level, increasing your overall productivity. There is a learning curve though, so be aware. [0] https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/ https://fsharpforfunandprofit.com/posts/designing-with-types...

carmate383 7y ago

Ah yes, a last ditch effort to claw back an inferior language into the popularity again. This is nothing more than a knee-jerk reaction to loss of market-share to TypeScript / Python / Name your other buzz-language here (R)

cutler 7y ago
Ruby inferior to Javascript and Python? What are you smoking? Python's BDFL begrudgingly added lambda to Python but amputated it to single-line expressions because he didn't want to "encourage" functional programming. By contrast Ruby is an artistically-curated blend of the best of Smalltalk, Lisp and Perl fully embracing functional programming. No contest.

ricardobeat 7y ago

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/ https://crystal-lang.org/

cyberferret 7y ago
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.
technion 7y ago
Why should the people who built and maintain Ruby focus their efforts on a different language?
- ricardobeat 7y ago
  You can ask the creator himself: https://github.com/mruby/mruby https://github.com/mruby/mruby
imhoguy 7y ago
Because it is about Rails and tons of useful gems which would need to be ported 1:1 to Crystal, plus keep compatibility with CRuby for some time. Too much effort which nobody would pay for.

zmmmmm 7y ago

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.

hrktb 7y ago
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.
sametmax 7y ago
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.
- paganel 7y ago
  > There is no such thing as the perfect language for everything anyway. People tend to forget this all to easily. For example most of the static type discussions for the past 10 years have taken place on a website built in a dynamic programming language, I'm talking about http://lambda-the-ultimate.org/ http://lambda-the-ultimate.org/ which afaik is built in Drupal (i.e. PHP).

cutler 7y ago

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

tomstuart 7y ago
How would you write the type of a function that takes a parameter called `returns`?
- cutler 7y ago
  Simple - make 'returns' a reserved word.
deleted 7y ago
[deleted]
bhuga 7y ago
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 `<main>' 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 `<main>' 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.
- mnarayan01 7y ago
  The parser thinks that's a block not a hash.
  - cutler 7y ago

cutler 7y ago

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.

adimitrov 7y ago
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 Haskell style to always annotate the type sigs of top-level functions. Why? Because they serve as more than just hints to the compiler: they are part (and a very important part!) of the documentation. That is why they're in-line. Because A function like zipWith:: [a] -> [b] -> (a -> b -> c) -> [c] tells you what it does in its type signature.
- cutler 7y ago
  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.
  - Faark 7y ago
    > 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.
    - mcintyre1994 7y ago
      It's been a while since I wrote Ocaml, but IIRC the compiler yells at you if your mli files are out-of-date, for whatever that's worth. So keeping them synced isn't really an issue.

localhostdotdev 7y ago

small discussion that was marked as dupe https://news.ycombinator.com/item?id=19696669 https://news.ycombinator.com/item?id=19696669

fulafel 7y ago

Ruby already had types, no? This is about static typing.

cies 7y ago
My thought too. Interesting what the definition of "static" will turn out to be in the context of something so inherently dynamic as Ruby.
viraptor 7y ago
If you're going for precision, then probably: type-annotations. The runtime doesn't change with sorbet. All the verification is via an external tool. So there's no static typing - your code can still violate the rules.

vemv 7y ago

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.

steveklabnik 7y ago
From the slides that are linked in the tweet in the tweet: https://sorbet.run/talks/RubyKaigi2019/#/45 https://sorbet.run/talks/RubyKaigi2019/#/45

gigatexal 7y ago

I hope Python 4 goes this route.

rswillif 7y ago

All of these beneficial refinements are meaningless if increasing performance optimization in the runtime isn't made more of a priority.

vemv 7y ago

Learning from the clojure.spec success story, what might make/break Sorbet is its runtime capabilities, aka reification. * Can I emit typed REST API docs out of sorbet types? * Can I coerce HTTP params out of sorbet types? * Can I emit ActiveRecord columns? ActiveModel validations? * Can I emit generative tests? You can do all of those (and whatever else you imagine) with clojure.spec in a DRY manner, i.e. types are defined once, and reused in a variety of contexts. As a Rails dev, I would greatly value all of those, particularly because they're practical things directly related to my webdev activity. Ensuring the type safety of the codebase is great, but also implicitly exercised by an adequate test suite.

ekvintroj 7y ago

There is something similar (but more powerful) for Smalltalk, it collects the types as you run the code and then it is used to improve the refactors. Check it out. https://github.com/hernanwilkinson/LiveTyping https://github.com/hernanwilkinson/LiveTyping

virtualwhys 7y ago

Great for Ruby (OP was arguably the most important compiler dev behind Martin Odersky on the Dotty/Scala 3 project), types for the win.

geraldbauer 7y ago

FYI: The RubyKaigi 2019 Progress Report on Ruby 3 Talk Slides have more (from the source) info. See the slides titled "Static Analysis" [1] Ruby 3 static analysis will have four items: 1. Type signature format 2. Level-1 type checking tool 3. Type signature profiling / prototyping tool 4. Level-2 type checking tools and so on. [1]: https://docs.google.com/presentation/d/1z_5JT0-MJySGn6UGrtdafK1oj9kGSO5sGlTtEQJz0JU/view#slide=id.g57cf166414_14_5 https://docs.google.com/presentation/d/1z_5JT0-MJySGn6UGrtda...

gkemmey 7y ago

Why do these efforts have to move into Ruby proper? Why can't sorbet or steep stay their own thing, and if it solves your Stripe-like-codebase problems, great. What I don't see a lot of here (or in general these days) is advocacy for the advantages of dynamic typing. And if you're objective, there most certainly are, even if they're not worth the disadvantages, or don't surpass the advantages of static typing for you, personally. But Ruby used to advocate for them, and it's definitely what drew me in. I find it disappointing that we're moving away from that. More and more, it seems we’re attempting to make Ruby all things to all people. Which eventually makes it the right thing for no one.

detaro 7y ago
How do optional typing annotations break ruby/Python/... for you?
- gkemmey 7y ago
  Well, I think there's a bit of mandatory-ness that comes with adding it to Ruby itself. Sounds like the standard library is going to ship with rbi files defined, for instance. Plus, tools for generating rbi files. On some level, it's an endorsement to do things this way, right? And that's before it (potentially) becomes a community practice to do so. If it's not, why not leave these solutions in gems? Btw, I don't think static typing alone is Ruby becoming all things to all people. In recent history, it's also aliasing `Enumerable#filter` to `Enumerable#select`, numbered block arguments, a shorthand special notation for `Object#method` -- it feels like a trend of "hey these other languages do this, we should too". I'm not convinced that's always the case.