Live data from Hacker News

Do I not like Ruby anymore? (2024)

sgt.hootr.club

171–180 of 184 posts

Re: Do I not like Ruby anymore? (2024)

#171
post #11

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

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.

Re: Do I not like Ruby anymore? (2024)

#172
post #23

Earlier quoted context omitted.

> that way lies madness. Flashbacks to scala operator PTSD. No. I don't want to use ++ ^^%% operator! I am not a number! I'm a man!

Scala3 fortunately fixed those.

Did it? Last time I checked, Scala 3 still has custom operators. The thing I'm making fun of is Scala's custom operator gibberish.

Re: Do I not like Ruby anymore? (2024)

#173

Earlier quoted context omitted.

> It would be like hating a screwdriver. I hate Philips screwdrivers (but love JIS).

Exactly! Both Python and Ruby are screwdrivers. In my highly opinionated opinion, the parallels are: - Flat head: Perl. Functional, and revolutionary at the time! But awkward to work with. - Phillips head: Python. Awesome improvement, much easier to work with. But still annoying in frustrating ways. - JIS: Ruby. A further refinement that resolves the last annoying 5% of work. (Well, OK, resolves 4 of the last 5%) ...…

Someone once said,

"Ruby is Scheme mated with Perl in such a way that the best genes of both failed to exert a phenotype."

Re: Do I not like Ruby anymore? (2024)

#174
post #99
post #74

Earlier quoted context omitted.

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?

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

heh, i got the opposite experience going from static to dynamic.

Re: Do I not like Ruby anymore? (2024)

#175

Earlier quoted context omitted.

If you do carpentry and you've previously lost a finger using a saw without a saw-stop, and now table saws with saw-stops are an option, you might rightly hate using table saws without one, to the point you wouldn't be willing to work at a shop that forces you to use one.

Whose forcing you to work at an unsafe shop?

your landlord.

Re: Do I not like Ruby anymore? (2024)

#176
post #42

What looks like stagnation to Steen is actually [1] Matz’s remarkable foresight that provided stability and developer happiness. Steen’s not wrong that Python evolved and Ruby moved slower, but he’s wrong to call Ruby stagnant or irrelevant. Just think what we've enjoyed in recent times: YJIT and MJIT massively improved runtime performance, ractors, the various type system efforts (RBS/Sorbet etc) that give gradual t…

My reaction to that part of the post was, “Well, it seems like Python needed to evolve while Ruby was better-designed from the beginning. That’s a failing of Python, not of Ruby.” Language stability is a good thing, which is why I prefer Clojure myself. I know enough Python and Ruby to be dangerous. I’m certainly no expert in either one. That said, Python always struck me as a bit of a hack, but people seemed to reso…

[deleted]

Re: Do I not like Ruby anymore? (2024)

#177

Earlier quoted context omitted.

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).

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.

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++.

Re: Do I not like Ruby anymore? (2024)

#180
post #37

Earlier quoted context omitted.

I am not an experienced programmer, but I liked python because of the dynamic typing, but tbh no type hints are a nightmare (as I used to use python). These days I gravitate towards using type hints unless I am using an ipynb because it looks clean, but it can be a little much, it can look quite ugly. Not every usecase needs type hints is what I've learned.

A good compromise can be for example: Have your type annotations in the head of the procedure you are writing. That includes types of arguments and return type. You write it once at the head, and when you need to know you can look it up there, but you don't need to clutter the whole rest of the code. If you write well composing functions, then this will be all you ever need. If you write procedures 300 LoC, then well…

There definitely is an element of shooting oneself in ones own foot, but sometimes it seems unavoidable to me, or the effort just isn't worth it e.g. if I am using sklearn or numpy and the return types are ambiguous, then I'd have to overload each function at the head of the file or wrap it although it is clear what it does. What do you think? I think that if it's only my own code, then yes this is certainly avoidable with good composing functions.
Post reply on HN