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

151–160 of 216 posts

Re: Types will be part of Ruby 3 stdlib source

#151

Post by queensnake »

mruts wrote: post #120
black-alert wrote: post #58

Earlier quoted context omitted.

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…

C/C++ doesn't really have much static typing to speak of. I don't think you are realizing the power of real statically type languages, such as Haskell, OCaml, or Scala.

Are you thinking of the way ints and chars (and floating-point types!) inter-convert? That is a weakness or convenience, but otherwise the typing is pretty strong.

Re: Types will be part of Ruby 3 stdlib source

#152

Post by [deleted] »

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…

[deleted]

Re: Types will be part of Ruby 3 stdlib source

#153

Post by rmsaksida »

cageface wrote: post #89
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.

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.

Re: Types will be part of Ruby 3 stdlib source

#154

Post by viraptor »

fulafel wrote: post #119

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

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.

Re: Types will be part of Ruby 3 stdlib source

#155

Post by hibikir »

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?

The story didn't start as 'add types to Ruby'. It starts from someone having a codebase in the hundreds of thousands of lines of Ruby, dedicated to financial software, and the costs that they had by trying to keep said codebase from costing a lot of money: In those situations, you can go as far as toevaluate how much each bug deployed to production cost you.

Quite a few large companies have found themselves in this situation: Very large codebases in a programming language without types stop being fast to develop in. Then you get to either rewrite everything, with the well documented risks, or start doing all kinds of other things to make programming safer, like banning certain parts of the language, until eventually dedicating a team to improve the language is the most cost effective way to go.

In this case, I am also pretty certain that the interaction with data started having informal types a while ago too.

What I find really interesting here is that what starts as a library to help a single company handle the subset of Ruby they were using in the first place now aims to be good enough for general purpose Ruby outside of said company. It's one thing to have problems with an experimental, home-made thing, and just get support via slack, but adding this to the language has a far higher barrier. This is also probably the reason it's not OSS yet: The code that is enough for production use in Stripe's approach to Ruby might not be the greatest in a random codebase with different opinions on how many dynamic methods you want to have.

So it's not that a team decides to add types to Ruby instead of just picking a language that already has the types: It's solving a private problem and, a while later, realize that accidentally the solution is very close to being good enough for the language.

Re: Types will be part of Ruby 3 stdlib source

#156

Post by ghostwriter »

readittwice wrote: post #96
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…

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

It's because PyPy relies on traced runtime statistics for optimizations via inlining. There's another approach where you translate your typed program into a lower-level target language and compile it into a native binary. See https://github.com/mypyc/mypyc and https://github.com/cython/cython/wiki/Python-Typing-Proposal

Re: Types will be part of Ruby 3 stdlib source

#157

Post by kgilpin »

z1mm32m4n wrote: post #51
joelbluminator wrote: post #45

Earlier quoted context omitted.

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?

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

I’m curious which projects you used to try this out on?

Re: Types will be part of Ruby 3 stdlib source

#158

Post by bjoli »

aasasd wrote: post #138
bjoli wrote: post #134

Earlier quoted context omitted.

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.

The slowness of brew isnt ruby's fault. They don't keep a local cache of the taps, but instead searches for taps using an API that interfaces with github and searches local taps, remote taps, then blacklisted taps and then probably something more. It is limited by network speed, not by string searching.

Edit: explained better here: https://github.com/Homebrew/brew/issues/3056#issuecomment-32...

Re: Types will be part of Ruby 3 stdlib source

#159

Post by kgilpin »

Shish2k wrote: post #82
tomc1985 wrote: post #26

Earlier quoted context omitted.

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

You could do this in C++ by storing the unit of measure with the measurement value and then performing unit conversion in overloaded math operators.

Re: Types will be part of Ruby 3 stdlib source

#160

Post by aasasd »

bjoli wrote: post #158
aasasd wrote: post #138

Earlier quoted context omitted.

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.

The slowness of brew isnt ruby's fault. They don't keep a local cache of the taps, but instead searches for taps using an API that interfaces with github and searches local taps, remote taps, then blacklisted taps and then probably something more. It is limited by network speed, not by string searching. Edit: explained better here: https://github.com/Homebrew/brew/issues/3056#issuecomment-32...

It's not limited by network speed because I have HOMEBREW_NO_GITHUB_API and HOMEBREW_NO_AUTO_UPDATE enabled. It's not like I just today stumbled into the problem.

Brew's not even consuming much system cpu time during `brew search`, despite hogging a core for a full minute.

Even just `brew help` takes almost 10 sec cold.

Post reply on HN