5 ms·

Back when autocompletion and stuff were only available in Visual Studio/Xcode/Other bug IDEs, I was forced to use Ruby and fell in love with it. It didn't matte

by pmkary 1y ago

Back when autocompletion and stuff were only available in Visual Studio/Xcode/Other bug IDEs, I was forced to use Ruby and fell in love with it. It didn't matter what I used as my editor was Sublime. But when VSCode came and language features became democratized, I never touched a type-less language again. Why should someone opt for a language with absolutely no features where one can have autocompletion, typechecking, deep data type exploration, jumping to definitions and implementations? I really think it's a bad choice of Ruby not to care for types. And well we now have Crystal which again makes me question why Ruby? And it’s a shame no language is as beautiful as Ruby, not in features choices, design elegance, balance, beauty of the syntax, joy of programming mindset, not even in the name and logo. I wished Matz rethinked this part.

javaunsafe2019 1y ago
Fully agree. Had to work in the past with ruby. Loved it but type errors during runtime where a thing and therefore I would never use ruby in production again. I use kotlin nowadays…
- koakuma-chan 1y ago
  I used Kotlin before it was popular and people laughed at me... And now I use TypeScript...
  - maccard 1y ago
    Kotlin is lovely to work with but holy hell is it slow to iterate on.
    - arunix 1y ago
      What does "slow to iterate on" mean?
zarzavat 1y ago
This was always true, to be honest. Statically typed languages have always been better. Free IDEs such as Eclipse have been available for a long time. Good JVM languages such as Scala have been available for a long time. If only the Ruby ecosystem had adopted Scala instead of Ruby, with cutesy books and eccentric underscored personalities, history might have been different.
- viraptor 1y ago
  There's also Crystal https://crystal-lang.org/ https://crystal-lang.org/
- agentcoops 1y ago
  I’m honestly still stunned at the self-implosion of the Scala community… can’t think of any other language that threw away such quite unexpected success at an industry level. Apart from the toxic community, not trying to challenge Python for supremacy in the scientific computing/data analysis space seems like the major mistake, given it was for a time the lingua franca of data infra (Spark, Scalding etc).
  - jackcviers3 1y ago
    You _can_ largely ignore the toxicity. Don't give toxic individuals attention, and they go somewhere else to stor the pot. Just debate the ideas with the merits in the source code, ignore the haters, and be kind and helpful. It's not difficult to do.
    - agentcoops 1y ago
      Oh for sure, I'm not too stressed by it -- but I think the ship has sailed on the chance for mainstream Scala adoption. Perhaps it was always delusional, but there was a period when it really seemed like Scala had somewhat of a chance to be the Ruby replacement and become one of the main backend languages (after the Twitter rewrite to Scala, when Foursquare, Meetup and various other startups of that generation were all in on the language); then there was a generation where at least it was the defacto language for data infra. Now, I'm not even sure if many major companies are even using it for the latter case. Mainstream adoption isn't everything and I still mostly use Scala for personal projects, but it's such a different world working in a language where the major open source projects have industry backing. The Scala community, meanwhile, seems mostly stuck starting entirely new FP frameworks every other week. Nothing against that, but I don't see that much advantage to choosing Scala over OCaml at this point (if you don't need JVM integration). Momentum appears to be behind Rust now, of course, but I've yet to be convinced. If it had a better GPU story and could replace C/C++ entirely I'd be on board, but otherwise I want my everyday language to be a bit closer to Python/Ruby on the scale against C/C++.
theshrike79 1y ago
LSP (Language Server Protocol) was the final nail in the coffin of Emacs for me. VSCode was "good enough" for pretty much every language with LSP at that point, I did't even bother with Jetbrains ides outside of work after that. And when Obsidian replaced org-mode for me, I deleted my .emacs directory from my dotfiles repository.
- themafia 1y ago
  > LSP (Language Server Protocol) was the final nail in the coffin of Emacs for me. It was the opposite for me. Emacs + LSP + many other common conveniences all bind together so beautifully and efficiently that I can't imagine using any other IDE at this point.
  - writebetterc 1y ago
    Same, Emacs is improving at a rapid rate thanks to its adoption of LSP and Tree-Sitter. Performance is very good, but the async story needs to become better.
  - austinjp 1y ago
    Indeed. I'm a long time Emacs user (emacs-nox in the terminal). After spending a day getting LSP and eglot working, I'm loving the "IDE" experience. Reliable indentation, auto-complete, intelligent var renaming, real-time(ish) warnings and error messages, etc, all the good stuff. I'd been ignoring IDE features in Emacs for years, thinking I didn't need them, but I have to admit they're a luxury I don't want to give up.
  - zkry 1y ago
    And I have to say that the whole trope of "Emacs may be able to do anything but you have to configure a lot to get it to work" has has got to be pure exaggeration at this point with things like eglot. I had the most painless experience setting up LSP for Java (among many others).
    - neutronicus 1y ago
      It is in fact pretty true with C++. Getting everything set up for jump to definition and find references to work with an existing code base ... can be a journey. If you are at a Visual Studio / XCode shop (where these things have been set up and work) you will definitely be swimming against the stream trying to get emacs to "speak" that codebase.
frou_dh 1y ago
Static type-signatures are inevitable in general. You can see this by how even the Ruby documentation has to make up silly ad hoc notation like "→ array_of_strings", "→ matchdata or nil" etc. (Random example): https://docs.ruby-lang.org/en/3.4/String.html#method-i-lines https://docs.ruby-lang.org/en/3.4/String.html#method-i-lines
- Lio 1y ago
  That's just documentation tool but the method is actually already statically typed by ruby. I'm not sure why they don't link that in the documenation but I beleive it is something the RDoc mainer wants to do. def lines: (?string? separator, ?chomp: boolish) -> Array[String] | (?string? separator, ?chomp: boolish) { (String line) -> void } -> self https://github.com/ruby/rbs/blob/master/core/string.rbs https://github.com/ruby/rbs/blob/master/core/string.rbs
matltc 1y ago
As someone coming from Ruby to TypeScript, I find types cumbersome, verbose, complex, and not of much use. I have been writing and reading TS for the past six months. What am I missing?
- nchmy 1y ago
  I've only used TS a bit, but I find the typing (and everything else) to be vastly more difficult/convoluted than in Go. Though, using Deno does help a lot (not necessarily with typing though).
- thaneross 1y ago
  If your only exposure to static typing is six months of TS, what you are missing is experience. You're still on the learning curve and thus the cognitive load of explicit types is high, but with time the opposite becomes true.
- jemiluv8 1y ago
  Typescript is not suitable for all applications. I also transitioned to Typescript from python some years ago and the extra information about "intent" provided by types made a world of difference to me when reading code written by other people. Type information is so valuable in a team of 3+ developers and when a rest api has at least 5+ resources. If your application or team size are any less, the benefits of typescript might not be obvious. I think that could be what you're experiencing. In a team, it is just so much easier to come across a "typed" function as opposed to an untyped one. You need to read the entire function to know what it is about.
  - hahn-kev 1y ago
    Totally agree. I've found that people who don't understand the value of types are usually solo devs
- jelder 1y ago
  I have been building web apps for long enough to remember when it was commonplace to SSH (or Telnet!) into the server and just vim index.php. As you can imagine, it was pretty easy to bring the site down like that, so we started doing what is now called Continuous Integration and Continuous Deployment: automated tests as a precondition for deployment. Later, we adopted static analysis tools and code linters. This helped, but only so much could be done with the dynamically typed languages which were popular in the early internet. As a self-taught programmer with no college degree, I started with dynamic languages: Perl, JavaScript, PHP, Ruby. I viewed the statically typed languages (and the programmers who could wield them) with reverence and awe. C, C++, Java, these were “real” languages that required big brains, and I should stay in my dynamically typed playpen. But as I matured, my understanding shifted: dynamic languages require hubris, require belief that you can keep an entire complicated codebase in your head with perfect recall. Statically typed languages, it turns out, invite humility. With a static type system, each step in a program’s lifecycle can be a little contract with itself. Break that contract and the language will tell you exactly how and where. These languages can provide immediate feedback to the developer about a program’s correctness before it is even run. Bridging the gap between all of the existing dynamic code (and the developers who wrote it) and the statically typed utopia lies so-called gradual type systems such as TypeScript. I like to use a meteorological analogy here: if JavaScript is “wintry mix,” then TypeScript lowers the temperature just enough to build a snowman.
pansa2 1y ago
> it’s a shame no language is as beautiful as Ruby [...] I really think it's a bad choice of Ruby not to care for types Do you think Ruby could change something so fundamental as dynamic => static typing and still retain its beauty? The only static typing solution I've seen for Ruby is Sorbet, and it's... not beautiful.
- kodablah 1y ago
  I use RBS/steep with great success to catch plenty of nil issues early, but it's similarly not great from a dev POV to have to maintain a completely separate set of rbs files (or special comments with rbs-inline). Also in my experience, modern editors don't leverage it for typing/intellisense.
- nithinbekal 1y ago
  Sorbet now supports inline RBS signatures, which I find a lot more readable. If you use VS code with Ruby LSP, the syntax highlighting is pretty great for the signatures too. https://sorbet.org/docs/rbs-support https://sorbet.org/docs/rbs-support
- jjice 1y ago
  Crystal [0] is what comes to mind. I've spent very little time with it, but I find the syntax very appealing. [0] https://crystal-lang.org/ https://crystal-lang.org/
- dbalatero 1y ago
  One of the main devs on Sorbet would agree: https://blog.jez.io/history-of-sorbet-syntax/ https://blog.jez.io/history-of-sorbet-syntax/
- JamesSwift 1y ago
  Based on what Ive read [1], Sorbet was born out of very specific circumstances at Stripe, in the same sort of way that go was at google. I think it missed the mark due to it being a specific tool for specific usecases instead of an "open source project for the general public" first. I love ruby but I do look forward to having a good option for types at some point. The community makes up for lack of types by adding more tests to their test suite, which is nice but I'd love to layer some encoding into the codebase itself and save the CI time. [1] - https://blog.jez.io/history-of-sorbet-syntax/ https://blog.jez.io/history-of-sorbet-syntax/
BariumBlue 1y ago
Lack of types is one thing that turned me away from Elixir when I was trying to learn it. I didn't know how to think about the types so I wanted some way to annotate them to help think through it, but went through it. And then the compiler complained at me I was passing in the wrong type to a function. I mean yes thanks? But also give me a way to figure that out BEFORE I try running the code.
- tasuki 1y ago
  Try Gleam!
JeremyNT 1y ago
I think Ruby is really great at what it tries to do. The only "problem" with it is that python kind of sucked the air out of the room and ruby got shoved into a little niche. These languages are really quite similar in many ways, but their domains ended up diverging. With python becoming the layman / scientific / learning language of choice, ruby has been pigeon holed into mostly web development. Both are really easy to pick up and learn for somebody unfamiliar with CS concepts and I personally find the ruby syntax far more intuitive. We have a lot more options now. For a while people tried to use python and ruby as glue / systems programming languages, but with golang and rust you have really good and more performant options in that space. And as you say the tooling has improved massively, so the hurdle of moving on to a more "rigid" language is less than it ever was. I still really like ruby, and I think rails is still a powerhouse due to solving so many real world problems in a really complete package, but the lack of adoption outside of that niche has left it dwindling in popularity.
- mixmastamyk 1y ago
  Python syntax is more intuitive for someone who initially learned C or Java, and for mainstream developers a point in its favor.
deleted 1y ago
[deleted]
AlwaysRock 1y ago
> jumping to definitions and implementations This is undervalued. So frustrating in ruby that this doesnt exist or at least isnt easy.
parentheses 1y ago
Typing not being a natively ruby thing makes all efforts to type the language in place seem second class. Ruby needs a typed variant that compiles down to type less Ruby.

by pmkary 1y ago

javaunsafe2019 1y ago

Fully agree. Had to work in the past with ruby. Loved it but type errors during runtime where a thing and therefore I would never use ruby in production again. I use kotlin nowadays…

koakuma-chan 1y ago
I used Kotlin before it was popular and people laughed at me... And now I use TypeScript...
- maccard 1y ago
  Kotlin is lovely to work with but holy hell is it slow to iterate on.
  - arunix 1y ago
    What does "slow to iterate on" mean?

zarzavat 1y ago

This was always true, to be honest. Statically typed languages have always been better. Free IDEs such as Eclipse have been available for a long time. Good JVM languages such as Scala have been available for a long time. If only the Ruby ecosystem had adopted Scala instead of Ruby, with cutesy books and eccentric underscored personalities, history might have been different.

viraptor 1y ago
There's also Crystal https://crystal-lang.org/ https://crystal-lang.org/
agentcoops 1y ago
I’m honestly still stunned at the self-implosion of the Scala community… can’t think of any other language that threw away such quite unexpected success at an industry level. Apart from the toxic community, not trying to challenge Python for supremacy in the scientific computing/data analysis space seems like the major mistake, given it was for a time the lingua franca of data infra (Spark, Scalding etc).
- jackcviers3 1y ago
  You _can_ largely ignore the toxicity. Don't give toxic individuals attention, and they go somewhere else to stor the pot. Just debate the ideas with the merits in the source code, ignore the haters, and be kind and helpful. It's not difficult to do.
  - agentcoops 1y ago
    Oh for sure, I'm not too stressed by it -- but I think the ship has sailed on the chance for mainstream Scala adoption. Perhaps it was always delusional, but there was a period when it really seemed like Scala had somewhat of a chance to be the Ruby replacement and become one of the main backend languages (after the Twitter rewrite to Scala, when Foursquare, Meetup and various other startups of that generation were all in on the language); then there was a generation where at least it was the defacto language for data infra. Now, I'm not even sure if many major companies are even using it for the latter case. Mainstream adoption isn't everything and I still mostly use Scala for personal projects, but it's such a different world working in a language where the major open source projects have industry backing. The Scala community, meanwhile, seems mostly stuck starting entirely new FP frameworks every other week. Nothing against that, but I don't see that much advantage to choosing Scala over OCaml at this point (if you don't need JVM integration). Momentum appears to be behind Rust now, of course, but I've yet to be convinced. If it had a better GPU story and could replace C/C++ entirely I'd be on board, but otherwise I want my everyday language to be a bit closer to Python/Ruby on the scale against C/C++.

theshrike79 1y ago

LSP (Language Server Protocol) was the final nail in the coffin of Emacs for me. VSCode was "good enough" for pretty much every language with LSP at that point, I did't even bother with Jetbrains ides outside of work after that. And when Obsidian replaced org-mode for me, I deleted my .emacs directory from my dotfiles repository.

themafia 1y ago
> LSP (Language Server Protocol) was the final nail in the coffin of Emacs for me. It was the opposite for me. Emacs + LSP + many other common conveniences all bind together so beautifully and efficiently that I can't imagine using any other IDE at this point.
- writebetterc 1y ago
  Same, Emacs is improving at a rapid rate thanks to its adoption of LSP and Tree-Sitter. Performance is very good, but the async story needs to become better.
- austinjp 1y ago
  Indeed. I'm a long time Emacs user (emacs-nox in the terminal). After spending a day getting LSP and eglot working, I'm loving the "IDE" experience. Reliable indentation, auto-complete, intelligent var renaming, real-time(ish) warnings and error messages, etc, all the good stuff. I'd been ignoring IDE features in Emacs for years, thinking I didn't need them, but I have to admit they're a luxury I don't want to give up.
- zkry 1y ago
  And I have to say that the whole trope of "Emacs may be able to do anything but you have to configure a lot to get it to work" has has got to be pure exaggeration at this point with things like eglot. I had the most painless experience setting up LSP for Java (among many others).
  - neutronicus 1y ago
    It is in fact pretty true with C++. Getting everything set up for jump to definition and find references to work with an existing code base ... can be a journey. If you are at a Visual Studio / XCode shop (where these things have been set up and work) you will definitely be swimming against the stream trying to get emacs to "speak" that codebase.

frou_dh 1y ago

Static type-signatures are inevitable in general. You can see this by how even the Ruby documentation has to make up silly ad hoc notation like "→ array_of_strings", "→ matchdata or nil" etc. (Random example): https://docs.ruby-lang.org/en/3.4/String.html#method-i-lines https://docs.ruby-lang.org/en/3.4/String.html#method-i-lines

Lio 1y ago
That's just documentation tool but the method is actually already statically typed by ruby. I'm not sure why they don't link that in the documenation but I beleive it is something the RDoc mainer wants to do. def lines: (?string? separator, ?chomp: boolish) -> Array[String] | (?string? separator, ?chomp: boolish) { (String line) -> void } -> self https://github.com/ruby/rbs/blob/master/core/string.rbs https://github.com/ruby/rbs/blob/master/core/string.rbs

matltc 1y ago

As someone coming from Ruby to TypeScript, I find types cumbersome, verbose, complex, and not of much use. I have been writing and reading TS for the past six months. What am I missing?

nchmy 1y ago
I've only used TS a bit, but I find the typing (and everything else) to be vastly more difficult/convoluted than in Go. Though, using Deno does help a lot (not necessarily with typing though).
thaneross 1y ago
If your only exposure to static typing is six months of TS, what you are missing is experience. You're still on the learning curve and thus the cognitive load of explicit types is high, but with time the opposite becomes true.
jemiluv8 1y ago
Typescript is not suitable for all applications. I also transitioned to Typescript from python some years ago and the extra information about "intent" provided by types made a world of difference to me when reading code written by other people. Type information is so valuable in a team of 3+ developers and when a rest api has at least 5+ resources. If your application or team size are any less, the benefits of typescript might not be obvious. I think that could be what you're experiencing. In a team, it is just so much easier to come across a "typed" function as opposed to an untyped one. You need to read the entire function to know what it is about.
- hahn-kev 1y ago
  Totally agree. I've found that people who don't understand the value of types are usually solo devs
jelder 1y ago
I have been building web apps for long enough to remember when it was commonplace to SSH (or Telnet!) into the server and just vim index.php. As you can imagine, it was pretty easy to bring the site down like that, so we started doing what is now called Continuous Integration and Continuous Deployment: automated tests as a precondition for deployment. Later, we adopted static analysis tools and code linters. This helped, but only so much could be done with the dynamically typed languages which were popular in the early internet. As a self-taught programmer with no college degree, I started with dynamic languages: Perl, JavaScript, PHP, Ruby. I viewed the statically typed languages (and the programmers who could wield them) with reverence and awe. C, C++, Java, these were “real” languages that required big brains, and I should stay in my dynamically typed playpen. But as I matured, my understanding shifted: dynamic languages require hubris, require belief that you can keep an entire complicated codebase in your head with perfect recall. Statically typed languages, it turns out, invite humility. With a static type system, each step in a program’s lifecycle can be a little contract with itself. Break that contract and the language will tell you exactly how and where. These languages can provide immediate feedback to the developer about a program’s correctness before it is even run. Bridging the gap between all of the existing dynamic code (and the developers who wrote it) and the statically typed utopia lies so-called gradual type systems such as TypeScript. I like to use a meteorological analogy here: if JavaScript is “wintry mix,” then TypeScript lowers the temperature just enough to build a snowman.

pansa2 1y ago

> it’s a shame no language is as beautiful as Ruby [...] I really think it's a bad choice of Ruby not to care for types Do you think Ruby could change something so fundamental as dynamic => static typing and still retain its beauty? The only static typing solution I've seen for Ruby is Sorbet, and it's... not beautiful.

kodablah 1y ago
I use RBS/steep with great success to catch plenty of nil issues early, but it's similarly not great from a dev POV to have to maintain a completely separate set of rbs files (or special comments with rbs-inline). Also in my experience, modern editors don't leverage it for typing/intellisense.
nithinbekal 1y ago
Sorbet now supports inline RBS signatures, which I find a lot more readable. If you use VS code with Ruby LSP, the syntax highlighting is pretty great for the signatures too. https://sorbet.org/docs/rbs-support https://sorbet.org/docs/rbs-support
jjice 1y ago
Crystal [0] is what comes to mind. I've spent very little time with it, but I find the syntax very appealing. [0] https://crystal-lang.org/ https://crystal-lang.org/
dbalatero 1y ago
One of the main devs on Sorbet would agree: https://blog.jez.io/history-of-sorbet-syntax/ https://blog.jez.io/history-of-sorbet-syntax/
JamesSwift 1y ago
Based on what Ive read [1], Sorbet was born out of very specific circumstances at Stripe, in the same sort of way that go was at google. I think it missed the mark due to it being a specific tool for specific usecases instead of an "open source project for the general public" first. I love ruby but I do look forward to having a good option for types at some point. The community makes up for lack of types by adding more tests to their test suite, which is nice but I'd love to layer some encoding into the codebase itself and save the CI time. [1] - https://blog.jez.io/history-of-sorbet-syntax/ https://blog.jez.io/history-of-sorbet-syntax/

BariumBlue 1y ago

Lack of types is one thing that turned me away from Elixir when I was trying to learn it. I didn't know how to think about the types so I wanted some way to annotate them to help think through it, but went through it. And then the compiler complained at me I was passing in the wrong type to a function. I mean yes thanks? But also give me a way to figure that out BEFORE I try running the code.

tasuki 1y ago
Try Gleam!

JeremyNT 1y ago

I think Ruby is really great at what it tries to do. The only "problem" with it is that python kind of sucked the air out of the room and ruby got shoved into a little niche. These languages are really quite similar in many ways, but their domains ended up diverging. With python becoming the layman / scientific / learning language of choice, ruby has been pigeon holed into mostly web development. Both are really easy to pick up and learn for somebody unfamiliar with CS concepts and I personally find the ruby syntax far more intuitive. We have a lot more options now. For a while people tried to use python and ruby as glue / systems programming languages, but with golang and rust you have really good and more performant options in that space. And as you say the tooling has improved massively, so the hurdle of moving on to a more "rigid" language is less than it ever was. I still really like ruby, and I think rails is still a powerhouse due to solving so many real world problems in a really complete package, but the lack of adoption outside of that niche has left it dwindling in popularity.

mixmastamyk 1y ago
Python syntax is more intuitive for someone who initially learned C or Java, and for mainstream developers a point in its favor.

deleted 1y ago

[deleted]

AlwaysRock 1y ago

> jumping to definitions and implementations This is undervalued. So frustrating in ruby that this doesnt exist or at least isnt easy.

parentheses 1y ago

Typing not being a natively ruby thing makes all efforts to type the language in place seem second class. Ruby needs a typed variant that compiles down to type less Ruby.