Hacker News Reader

Comment by ajmurmann | Hacker News Reader

Ruby used to be my most beloved language. I've since developed a strong appreciation for good type system. However, working with collections of any kind in Ruby is just such a joy. The methods around it are so well thought throug and make writing code a joy that in most other languages just would be tedious. On top of that the Ruby team is constantly working on making that aspect even better. I truly don't understand why it seems to me that no other language I use makes even an effort to provide something similar. Getting a map, a reduce and a filter function seems to be as far as most standard libraries are willing to go.

View on HN

Try Crystal and you get the joy of Ruby enumerables together with a static type system.

Crystal is nice, but my love affair with Swift is going strong. Not exactly Ruby syntax but pretty similar in terms of simplicity. I am a Rubyist who feels right at home with Swift. But for the new year, I definitely want to give Crystal a fair shot!

Kotlin is my new love. Best collections library of any language I've used, great type system, coroutines are amazing, and all of it integrates perfectly with 25 years of rock-solid Java libraries.

While the collections library may be better than others, it has a great many warts, many of which aren't discoverable until you've used it a long time. Some of these warts are a result of JVM interop requirements. It's not just the collections library, while the language is great and better than others, there are mounds of bugs and poor design decisions.

What do you use Coroutines in a static language like Java, for ?

Everywhere I used to use CompleteableFutures, except without ending up with completely unmaintainable code.

https://github.com/Kotlin/kotlinx.coroutines/blob/master/cor...

Very interesting, thanks!

Interesting. What’s your opinions on Crystal right now as a substitute for Ruby? Is there a good stack like Rails for Crystal?

Take a look at Lucky framework!

https://luckyframework.org

Quite immature, especially when it comes to community and library support.

But dang it's nice to do stuff in it.

Crystal is definitely not production ready, I mean a language without thread support...

Yeah, it’s only now MT schedulers is work in progress to bring multithread fibers to Crystal

https://github.com/crystal-lang/crystal/pull/7214

Thread support in interpreted languages isn’t that parallel to begin with.

JRuby threads are fully parallel and in production use today. CRuby's GIL is an implementation choice rather a property of dynamic/interpreted languages.

I’m wondering.. what is the effect of letting the JVM handle synchronization then ? Wouldn’t they still need to synchronize within JvM ?

Is it really a "choice" if the alternative is really hard to achieve in practice? It's like calling python's GIL a choice... with numerous projects trying to get rid of it in various ways and never really succeeding to do it while keeping the single threaded performance and the extensions API.

It is a choice to keep backwards compatibility with the C extensions API.

The GIL would be quite easy to replace otherwise.

> It is a choice to keep backwards compatibility with the C extensions API.

IIUC for CRuby it's mostly about how to keep the VM simple. Koichi Sasada is working on an ownership based model like Erlang has, which sidesteps a bunch of theses issues.

Try Kotlin and its collections.

I used to love Ruby too but the dynamic typing quickly became a deal breaker. So I set out to find a language that's as pleasant to use on a daily basis, with well designed libraries and collections, but also statically typed.

Kotlin met all these requirements for me.

You should try smalltalk :)

My thoughts exactly. I feel it isn’t the library, but the grammar, which is why the same feel cannot be replicated by other languages. Ruby is just easy on collections.

Can you comment on why a good type system became so important to you? I can understand the value in interfaces but not really in any other context.

Fewer run time errors. Easier testing, among other things.

Not having `nil` is soooo nice. I can't count the number of `Runtime Error`s because some method isn't defined on `NilClass` that have blown things up in weird edge cases.

Knowing exactly what types a method takes and the compiler catching incorrect uses before the code ever runs saves a lot of frustration. Another thing I've enjoyed in Rust include `match` clauses forcing me to define branches for any possibility, especially for `Result` structs. In ruby this isn't possible because anything can be anything.

There's got to be more to it than "has / doesn't have nil". Lisp has nil, and I rarely if ever see an analogous error there, or even a type error.

I have a hunch that single/static dispatch is what tends to cause more problems than merely the presence of nil. It's not nil, but how you use it.

"It's not nil, but how you use it."

Can you elaborate on how multi-dispatch reduces the issue of nil/null?

I also use static type (typescript) to prevent issues with nil and would like to know how I can achieve the same in a dynamic language.

You can prevent nil errors using contracts like in Eiffel and Clojure.

For a non-strong-typed language, it's difficult to dive into the code after you haven't work on that codebase for a while.

We were on a really old Mongoid (or carrierwave, or some other gem, can't remember), It was difficult to find the right methods to use and etc.

I understand it was our own fault not to write comprehensive tests or keep all gems up-to-date.

But a dynamic typing language is a lot more "punitive" when we aren't writing perfect code, using perfect design, and/or exercising perfect engineering practices.

Languages without ADTs and Optionals just feel impoverished.

Languages without full blown union types feel so impoverished. With good language typing support (including flow typing), optionals feel quite redundant.

But optionals are just a union type (T | None).

Languages without dependent types feel that something is still missing.

The === for Range and Datetime serves as a one example, with a good type system they wouldn't be directly comparable.

I can't type up a full answer right now, but for me, a strong type system is about being able to model my domain and bake all of my assumptions about that domain into the types I define.

It's a lot easier for me to reason about and avoid edge cases when I can (more or less) verify at compile time that invalid states are impossible.

This is about more than just catching null values, and also encompasses things like mutually exclusive fields, and access control.

If you're interested, I gave a talk once that dives into these ideas more effectively than I can express in this comment: https://github.com/ShaneWilton/programming-with-types-talk/b...

what bout clojure?

Clojure's stdlib is unintuitive, and `into` is the poster child.

It's easy to find what's available in Ruby: https://ruby-doc.org/core-2.5.3/Enumerable.html

Good luck with Clojure: https://clojure.github.io/clojure/clojure.core-api.html

https://re-find.it ?

I'm talking about the flat namespace.

While I understand the sentiment that all the functions aren't necessarily grouped as in OO languages, I think the Clojure functions are harder to group because they're more general. That's not necessarily the strongest argument, but it is so much more obvious in OO because you always have the object to group by compared to functional languages.

https://clojuredocs.org/ is what I always used. I dislike ruby's docs actually. Rust and Crystal have better UX design for their docs.

Oh boy, you are in for some treat if you try Clojure. But be warned, love for Ruby will be gone.

Can you recommend a post/article explaining some of what makes Ruby's collections especially pleasant? Studying Ruby's stdlib design has been on my 'someday' list, but there's so much else there...

It's mostly how complete the API is and how consistent. For example: * Hash#merge takes a block for conflict resolution. I use this all the time for aggregating counts. * #sample * #unique * Everything has a change in place option by appending "!"

Also, chaining is extremely concise. e.g. "products.map(&:cost).sort.last"

I couldn't resist...

Your example could be improved by using "products.sort_by(&:cost).last"

I try to not use map because often there are methods that already implement filtering. Gotta love Ruby readability.

I think you need `products.sort_by(&:cost).last.cost` for the same result.

You’re correct!

one beautiful design decision ruby made really on was that every method would have the option to take a block of code when it was invoked. the code block gets passed to the method as a closure. this makes writing collection apis very pleasant, since so many of them involve passing in a single closure to operate on each element.

Groovy. Probably because Groovy borrowed quite a lot from Ruby.

Apache Groovy even borrowed its name from Ruby -- it's really Gruby, if you get what I mean. And of course Grails started off as a clone of Rails.

Definitely. I dabbled in Ruby but kept coming back to Groovy because it had all the nice syntax of Ruby but all the advantages of the JVM, solid Java ecosystem / libraries and optional strong / static typing to apply when valuable (eg: defining interfaces or data types).

The only collection I wish Ruby improved upon is a simple Lisp style linked list. Kind of amazed JS has an easier way to do cdr than Ruby:

    const list = [ 1, 3, 4, 2, 8, 5];
    const [fst, ...snd] = list;

But I suppose that's just a result of JS implementing pseudo-pattern matching.

    head, *tail = *list

Has worked since 1.8. Don't ask me how I know that :-P

Damn, I should have remembered that. Especially considering I had a project where I had to trawl through the ruby parser including multiple assignment rules.

To be fair, I find the destructuring syntax strange in Ruby. For example, why do I need the splat on the list? It doesn't make sense to me. I'm sure there is a good reason buried in the implementation, but if I were to design the syntax, I don't think I would do it that way.

> For example, why do I need the splat on the list?

You don't on the RHS, or rather, it's redundant in the given example. On the LHS you need it to prevent single element capture.. and within the ruby language, it's a fairly consistent sigil.

Wow. You're right. I'm not sure how I got that wrong. I'm sure I tried it. Thanks for correcting me!

How is this different than splatting (my lisp is not so great.)?

https://repl.it/repls/EcstaticLamePaint

There's always Elixir :)

Reply on news.ycombinator.com