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

Open-sourcing the Sorbet VS Code Extension

sorbet.org

Post reply on HN
Print view View original

71–80 of 88 posts

Re: Open-sourcing the Sorbet VS Code Extension

#71

Post by ksec »

jzoch wrote: post #36
cutler wrote: post #28

It's funny how we hear so much about Ruby's decline yet 3 of the highest-valued startups - Stripe, Shopify and AirBnB - are up there making fortunes with it whilst contributing to Ruby's vibrant ecosystem.

Stripe is actively moving away from Ruby to Java. All new services must be written in Java

I upvoted you only to get attention. You will need reference for this.

>But nearly all of Stripe’s codebase is implemented in Ruby running on the default Ruby VM (YARV). Not only did we not need Java VM-level interoperability, choosing either alternative Ruby implementation would have made for a difficult migration path.

https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-comp...

Re: Open-sourcing the Sorbet VS Code Extension

#72

Post by newlisp »

mpd wrote: post #53
newlisp wrote: post #22

Earlier quoted context omitted.

A robust performant multithreaded runtime with a big set of enterprise libraries for the big boys.

That explains the JVM, but why Java , specifically? JRuby offers everything you mention.

Jruby is anything but performant when compared to Java, there's overhead.

Re: Open-sourcing the Sorbet VS Code Extension

#73

Post by zomgwat »

square_usual wrote: post #38
jez wrote: post #2

Happy to answer any questions about Sorbet, the VS Code extension, or anything else you're curious about!

Two questions (sorry if that's too much): 1. Sorbet isn't really great to use with Rails. I tried it out about a year ago - a few things might've changed but from scanning the relevant gems I think this broadly still applies. I used sorbet-rails but there were still a bunch of rough edges, eg. with using a class method on a model as a scope. The general theme was that Rails was doing quite a few things that make it s…

Regarding Sorbet and Rails, I recommend Tapioca [1].

The Rails app that I worked on had a few edge cases Tapioca didn't cover so I wrote a simple script to load the Rails app and generate RBI files (e.g. generate RBI definitions for fixture methods in ApplicationTestCase). The Tapioca codebase helped provide a path for that [2]. Tapioca also continues to add to their DSL compilers. The work to integrate Sorbet paid off very quickly.

Also, T::Enum and T::Struct are handy in any Ruby codebase.

[1] https://github.com/Shopify/tapioca [2] https://github.com/Shopify/tapioca/tree/main/lib/tapioca/com...

Re: Open-sourcing the Sorbet VS Code Extension

#74

Post by kache_ »

0x640x6D wrote: post #68
kache_ wrote: post #66

Earlier quoted context omitted.

If you look at all the job postings for Stripe, you'll notice that none of them require you to know ruby and expect you to be able to learn it on the job.

Right, which would indicate that they have more or less given up on appealing to ruby devs specifically. I work at a ruby only shop and we are the same way. I would say only about 30% of the candidates I interview have any ruby experience and of those, maybe 50% have recent experience. We would prefer to hire talented ruby devs, but they just aren't there.

what does talented even mean? If anyone is a not a shitter they should be able to be productive with ruby in the order of weeks

Re: Open-sourcing the Sorbet VS Code Extension

#76

Post by jez »

ksec wrote: post #75
jez wrote: post #2

Happy to answer any questions about Sorbet, the VS Code extension, or anything else you're curious about!

I know Shopify are using it [1], Do you know if Github or Basecamp are using it too? [1] https://twitter.com/rafaelfranca/status/1479259699694477312

I haven't heard anything from GitHub one way or another about whether they use Sorbet.

I'd be extremely surprised if Basecamp was using it, as DHH has always been particularly opposed to types, but again, I haven't heard anything one way or another from them.

Re: Open-sourcing the Sorbet VS Code Extension

#77

Post by jez »

bilekas wrote: post #57
jez wrote: post #2

Happy to answer any questions about Sorbet, the VS Code extension, or anything else you're curious about!

This might be a dumb question but is there a chosen license for the this source ?

We open sourced it by merging it into the Sorbet repo, under which all code is Apache 2.0 licensed:

https://github.com/sorbet/sorbet/blob/master/LICENSE

Re: Open-sourcing the Sorbet VS Code Extension

#78

Post by hota_mazi »

pantulis wrote: post #56
hota_mazi wrote: post #37

Earlier quoted context omitted.

The same argument can be made of PHP, COBOL, or even FORTRAN. None of this is changing the fact that Ruby has been on a sharp decline for a decade now and it's probably never coming back. My personal interpretation: Ruby is extremely slow, dynamically typed, and RoR hasn't kept up with the web innovations of the past decade.

Of course it will come back, you just need to wait until dynamic typing becomes fashionable again. Development time is still more important than operational speed.

I very much doubt dynamic typing will ever come back, it's a thing of the past now. No sane new project will ever start in a dynamically typed language.

Modern statically typed languages do everything that dynamic languages do and a lot more.

Re: Open-sourcing the Sorbet VS Code Extension

#79

Post by comp_throw7 »

IshKebab wrote: post #60
comp_throw7 wrote: post #51

Earlier quoted context omitted.

Yeah, Typescript is a complete no-brainer as a pick - even if you're only picking a backend language. The type system is better than anything this side of Haskell, while still letting you write boring imperative code without getting in your way for every little thing if you just need to pipe some data around. Performance is really not an issue unless you're doing very CPU-intensive work which you can't offload to a n…

Rust's type system is also better than Typescript, and I would say Dart is slightly better too. But I agree Typescript is very very good, and you get access to such an enormous ecosystem it's worth it in most cases, and it's only a few times slower than C++/Rust. Not 50 times like Python or Ruby.

I'll grant that Rust could make a solid argument for itself with traits and such (though I haven't had a chance to use it myself). What's the five-second rundown on Dart's type system being better than Typescript's? I take a look every couple years and back in the day I remember thinking it was a solid alternative to C#/Java simply for its better null handling but Typescript solved that problem and many others besides.

Re: Open-sourcing the Sorbet VS Code Extension

#80

Post by Matthias247 »

cutler wrote: post #61
Matthias247 wrote: post #48

Earlier quoted context omitted.

Not at Stripe, but I guess it was picked as a compromise between efficiency and developer productivity. Dynamic languages like Ruby and Python don't perform well in the first area, native languages like C++ not much in the latter. Rust might be better, but it's still harder to learn than Java and there's less experienced developers to hire. That tradeoff usually leads companies to pick one of Java, C# or Go.

Why not Kotlin as it's arguably closer to Ruby?

Maybe Java includes the possibility to use Kotlin? At many teams I know its up to the team to write parts of Java libraries or services within Kotlin since it's mostly an implementation detail. But again - I'm not part of Stripe so I can't talk for them.
Post reply on HN