Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Static Typing for Ruby: Adopting Sorbet at Scale

shopify.engineering

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#61

Post by resonious »

aerovistae wrote: post #18

This looks great in general, but does anyone else find Sorbet's signature formulation offputting? Feels cluttered and not at-a-glance readable. > sig {params(name: String, id: String).returns(Integer)} My ruby isn't quite good enough to parse the language constructs that make up that line, but it's not pretty. I guess....sig is a class method which takes a block....and params is a class method (Added to BasicObject o…

I imagine they could (in theory) simplify it to

  sig(name: String, id: String).returns Integer
Losing the block maybe has some undesirable performance implications, but it looks a little nicer without the curly braces.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#62

Post by viraptor »

d3nj4l wrote: post #57
viraptor wrote: post #52

Earlier quoted context omitted.

It goes past syntax. Yes, they're different languages, but syntax, behaviour, stdlib are so close you can port non-trivial libraries between them in a relatively short time.

The key word there is non trivial . Something with as many moving parts as Rails is non trivial, and Crystal doesn't have the run-time metaprogramming that Rails makes extensive use of. A trivial example is ActiveRecord generating attribute methods from your `select` operation.

I don't think rails is a fair example. Rails loves its runtime metaprogramming and that is not where crystal offers much, but I don't think it invalidates the overall similarity. There's trivial (scripts with simple flow), non-trivial (libraries with heavy oop design and a little bit of trickery), and there's almost everything else before we get to rails itself.

Just like in C, you have trivial, nontrivial, complex apps, then there's still a long way before production OS kernels at the extreme.

Many advanced libraries don't use metaprogramming much, and even if they do, it can be often made either more explicit or shifted to compile time.

Edit: The downvotes are interesting since the portability claim comes from my experience doing just that.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#64

Post by mperham »

nextos wrote: post #10
cplanas wrote: post #6

Earlier quoted context omitted.

> MRI Ruby was slow and problematic. Why problematic? On the slowness, I would agree that Ruby is slower than many languages, but as an interpreted language this is -up to a certain point- by design, or at least an accepted part of the trade-off one accepts when he takes a programming language. Moreover, Ruby's natural competitor is Python, not -say- Clojure; and I wouldn't that Ruby is significantly slower than Pyth…

It had lots of memory leaks. I love Ruby, and I used it anyway, but this bothered me a lot back in the mid-to-late 2000s.

The ever present memory bloat with Ruby has been discovered to be a glibc issue. Jemalloc makes MRI memory usage much more predictable and stable.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#65

Post by bastawhiz »

viraptor wrote: post #62
d3nj4l wrote: post #57

Earlier quoted context omitted.

The key word there is non trivial . Something with as many moving parts as Rails is non trivial, and Crystal doesn't have the run-time metaprogramming that Rails makes extensive use of. A trivial example is ActiveRecord generating attribute methods from your `select` operation.

I don't think rails is a fair example. Rails loves its runtime metaprogramming and that is not where crystal offers much, but I don't think it invalidates the overall similarity. There's trivial (scripts with simple flow), non-trivial (libraries with heavy oop design and a little bit of trickery), and there's almost everything else before we get to rails itself. Just like in C, you have trivial, nontrivial, complex a…

Shopify uses Rails. To your original question, which you've answered yourself: that's why they haven't joined forces. They were very clear in the article about the size and activity of their codebase, and their commitment to Rails in particular.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#66

Post by viraptor »

bastawhiz wrote: post #65
viraptor wrote: post #62

Earlier quoted context omitted.

I don't think rails is a fair example. Rails loves its runtime metaprogramming and that is not where crystal offers much, but I don't think it invalidates the overall similarity. There's trivial (scripts with simple flow), non-trivial (libraries with heavy oop design and a little bit of trickery), and there's almost everything else before we get to rails itself. Just like in C, you have trivial, nontrivial, complex a…

Shopify uses Rails. To your original question, which you've answered yourself: that's why they haven't joined forces. They were very clear in the article about the size and activity of their codebase, and their commitment to Rails in particular.

That wasn't my question :-) I was only addressing the syntax similarity bit since it's repeated write a lot.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#67

Post by rattray »

resonious wrote: post #61
aerovistae wrote: post #18

This looks great in general, but does anyone else find Sorbet's signature formulation offputting? Feels cluttered and not at-a-glance readable. > sig {params(name: String, id: String).returns(Integer)} My ruby isn't quite good enough to parse the language constructs that make up that line, but it's not pretty. I guess....sig is a class method which takes a block....and params is a class method (Added to BasicObject o…

I imagine they could (in theory) simplify it to sig(name: String, id: String).returns Integer Losing the block maybe has some undesirable performance implications, but it looks a little nicer without the curly braces.

I think they did this originally but the performance implications were a deal breaker, and had to move to blocks. Iirc, which is questionable.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#68

Post by dj_mc_merlin »

jez wrote: post #55
dj_mc_merlin wrote: post #54

> Finally, we track how many times our developers ran the command dev tc to typecheck a project with Sorbet on their development machine. How? Do they track all of their devs commands?

`dev tc` is a command at Shopify that runs Sorbet. I'm assuming they instrument all subcommands of their `dev` command and send aggregate statistics to an internal statsd service. We do the same thing where I work. If you're working on a developer productivity team, the service whose SLA you're responsible for is the dev tools, so it's critical to know how long they take, which commands are run most frequently, etc.…

Thanks!

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#69

Post by colinramsay »

I'm not sure about Sorbet. Shopify are definitely talking the talk but the issues list on GitHub is getting pretty large and the much-trumpeted VSCode plugin has disappeared. My first foray was cut short by a bug (https://github.com/sorbet/sorbet/issues/3603). With the up and coming typing support in Ruby 3 there's competition, which is good, but given the current state of play I'm going to wait for things to settle before trying to adopt again.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

#70

Post by vinceguidry »

zeckalpha wrote: post #59
vinceguidry wrote: post #53

Earlier quoted context omitted.

> drop into an irb in a running process This is a thing?

It also is a thing in most other languages, including C, Python, Java, Erlang, ...

I'm not so sure. You can certainly attach a debugger to any running process. But that's not what parent was suggesting. He was saying anyone could attach a REPL. That's a totally different animal.

It's your own dumb fault if you expose the web-console or similar on production.

Post reply on HN