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

81–88 of 88 posts

Re: Open-sourcing the Sorbet VS Code Extension

#81

Post by 0x640x6D »

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

Earlier quoted context omitted.

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

Yeah, duh, that's why we hire devs with any talent -- like I said. I'm not sure what you are pushing back against?

The contributions of a senior ruby engineer in a large, complex rails codebase will be immediate and will have a long tail over someone that has no experience in rails or ruby. This seems self-evident to me. It's just that there aren't enough of them.

Re: Open-sourcing the Sorbet VS Code Extension

#82

Post by yashap »

comp_throw7 wrote: post #79
IshKebab wrote: post #60

Earlier quoted context omitted.

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

I think the main issue with TypeScript’s type system is that most of the time, there’s no runtime types. You know something matches an interface, but if you have some untyped object (like say a thrown error from some lib that you caught), and you need to check if it’s a X, often it’s pretty awkward and hacky to do so. Obviously this issue is inherited from JS, but it’s still an issue.

Great type system and language otherwise, though.

Re: Open-sourcing the Sorbet VS Code Extension

#83

Post by IshKebab »

yashap wrote: post #82
comp_throw7 wrote: post #79

Earlier quoted context omitted.

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

I think the main issue with TypeScript’s type system is that most of the time, there’s no runtime types. You know something matches an interface, but if you have some untyped object (like say a thrown error from some lib that you caught), and you need to check if it’s a X, often it’s pretty awkward and hacky to do so. Obviously this issue is inherited from JS, but it’s still an issue. Great type system and language o…

That's not an issue if you code properly. Most statically typed languages only have run-time type information as a sort of "ok fine if you're desperate you can use it, but please don't" feature.

Exceptions are a special exception in Typescript because they can come from pretty much anywhere so it can't realistically know the type at compile time.

For everything else you are probably want discrimination unions.

Re: Open-sourcing the Sorbet VS Code Extension

#84

Post by janglezz »

hota_mazi wrote: post #78
pantulis wrote: post #56

Earlier quoted context omitted.

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.

I’d bet against this. Ruby has a great community and Rails 7 is looking amazing. Dynamic typing is very much alive and well.

Re: Open-sourcing the Sorbet VS Code Extension

#85

Post by esprehn »

rufugee wrote: post #65
cutler wrote: post #61

Earlier quoted context omitted.

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

Yeah, I would be interested in the logic here. I'd assume Kotlin to be a far more productive language for ex-rubyists than Java. Perhaps it's that they don't believe in the future of Kotlin outside of mobile?

In my experience it's usually JVM at these companies, not specifically Java, and certainly in recent years more and more teams use Kotlin for backend services.

Re: Open-sourcing the Sorbet VS Code Extension

#86

Post by yashap »

IshKebab wrote: post #83
yashap wrote: post #82

Earlier quoted context omitted.

I think the main issue with TypeScript’s type system is that most of the time, there’s no runtime types. You know something matches an interface, but if you have some untyped object (like say a thrown error from some lib that you caught), and you need to check if it’s a X, often it’s pretty awkward and hacky to do so. Obviously this issue is inherited from JS, but it’s still an issue. Great type system and language o…

That's not an issue if you code properly. Most statically typed languages only have run-time type information as a sort of "ok fine if you're desperate you can use it, but please don't" feature. Exceptions are a special exception in Typescript because they can come from pretty much anywhere so it can't realistically know the type at compile time. For everything else you are probably want discrimination unions.

Yeah, for your own code it’s not really an issue, as long as you’ve got decent team-wide discipline. But when integrating with external libraries, especially JS ones with type definitions tacked on later, it can be an annoyance.

Re: Open-sourcing the Sorbet VS Code Extension

#87

Post by comp_throw7 »

yashap wrote: post #82
comp_throw7 wrote: post #79

Earlier quoted context omitted.

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

I think the main issue with TypeScript’s type system is that most of the time, there’s no runtime types. You know something matches an interface, but if you have some untyped object (like say a thrown error from some lib that you caught), and you need to check if it’s a X, often it’s pretty awkward and hacky to do so. Obviously this issue is inherited from JS, but it’s still an issue. Great type system and language o…

Yeah, the story for handling thrown errors is much worse than it is in Java, and arguably worse than e.g. C#. But it's not a total loss:

1) 99.9%+ of the time, it'll be an instance of `Error` or some child class.

2) There's a recent compiler flag that's been added which defaults caught errors to `unknown` rather than `any`.

3) You still have access to the same tools to inspect unknown errors as you do everything else - `instanceof`, checking the presence/absence of properties, etc.

It's not great but it's something.

I would actually say the propensity of libraries to use exceptions as control flow and then _fail to document anything about those totally expected outcomes_ is a much bigger headache; that truly is an artifact of its JS inheritance.

Re: Open-sourcing the Sorbet VS Code Extension

#88

Post by kache_ »

0x640x6D wrote: post #81
kache_ wrote: post #74

Earlier quoted context omitted.

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

Yeah, duh, that's why we hire devs with any talent -- like I said. I'm not sure what you are pushing back against? The contributions of a senior ruby engineer in a large, complex rails codebase will be immediate and will have a long tail over someone that has no experience in rails or ruby. This seems self-evident to me. It's just that there aren't enough of them.

I'm pushing back because I've had the opposite experience. I've started in a new team with exceptionally talented people, all of whom who have never written a line of ruby, all providing incredible contributions and hitting all our (pretty crazy) dates. All in a large highly complex ruby monolith.

It takes like 1 month to ramp on ruby, maybe even less. The cost of one month of ramp is highly justifiable given the fact that it's hard to find anyone who knows ruby (for real knows ruby) & most of the ramp is on system specifics anyways

Post reply on HN