11–20 of 58 posts
This is orthogonal to tenderlove's GC work, but if you're using MRI and want an easy memory usage/performance win, swap out the standard glibc malloc for jemalloc: https://www.levups.com/en/blog/2017/optimize_ruby_memory_usa...
This is orthogonal to tenderlove's GC work, but if you're using MRI and want an easy memory usage/performance win, swap out the standard glibc malloc for jemalloc: https://www.levups.com/en/blog/2017/optimize_ruby_memory_usa...
Kind of a tangent, but does anyone know why glibc’s allocator loses to jemalloc on common workloads? I would expect that would be something worth rectifying unless other requirements tie their hands.
jemalloc likely wins more for the kinds of allocations you find in scripting language runtimes, which also happens to be similar to a browser given DOM & JS
Earlier quoted context omitted.
Exactly. As a Ruby developer, Crystal makes me itch . It jettisons exactly what Ruby is valuable to me for: quickly and dynamically building fluent-feeling libraries and tools. It's fast, but I don't need fast--if I don't need Ruby's metaprogramming, I have other, better, established languages to use for those tasks. (Kotlin, C#, Rust, whatever.) Elixir is kind-of in the same boat for me. I think it's neat and has it…
Have you used a recent (2017) version of Crystal? Quickly building fluent-feeling libraries and tools is exactly my use case for Crystal. For me, everything that Ruby is valuable for is retained. I'm able to do all the things I did in Ruby just fine, and it prevents me from doing a lot of things I shouldn't have been doing. We recently migrated our app from Rails to Crystal (using the Amber framework) and our code ba…
I have Kotlin, C#, C++, and Rust if I need static typing. Ruby is for when I don't.
Earlier quoted context omitted.
Have you used a recent (2017) version of Crystal? Quickly building fluent-feeling libraries and tools is exactly my use case for Crystal. For me, everything that Ruby is valuable for is retained. I'm able to do all the things I did in Ruby just fine, and it prevents me from doing a lot of things I shouldn't have been doing. We recently migrated our app from Rails to Crystal (using the Amber framework) and our code ba…
Until I can perform runtime define_method calls and dynamically construct classes, it doesn't matter what Crystal does. It's fundamentally antithetical to my needs. (JavaScript isn't, but JavaScript is kind of clunky.) I have Kotlin, C#, C++, and Rust if I need static typing. Ruby is for when I don't.
I occasionally wonder whether it might be possible to accommodate more dynamic language features with a compiler that treats them like a macro system that is expanded statically, such that no actual dynamicism is necessary at runtime.
What I'd like to be able to do is load ActiveRecord (or any other v. heavy lib) asynchronously in non web-based apps so that I can paint the UI quicker. By the time the user will do/need anything db-related a proxy object should be swapped out for an actual ActiveRecord object. Using Rails' ORM is so nice and ergonomic but it kills start-up time with all the file requires, Bootsnap helps a bit but I'd prefer not to h…
What I'd like to be able to do is load ActiveRecord (or any other v. heavy lib) asynchronously in non web-based apps so that I can paint the UI quicker. By the time the user will do/need anything db-related a proxy object should be swapped out for an actual ActiveRecord object. Using Rails' ORM is so nice and ergonomic but it kills start-up time with all the file requires, Bootsnap helps a bit but I'd prefer not to h…
Earlier quoted context omitted.
Have you used a recent (2017) version of Crystal? Quickly building fluent-feeling libraries and tools is exactly my use case for Crystal. For me, everything that Ruby is valuable for is retained. I'm able to do all the things I did in Ruby just fine, and it prevents me from doing a lot of things I shouldn't have been doing. We recently migrated our app from Rails to Crystal (using the Amber framework) and our code ba…
Until I can perform runtime define_method calls and dynamically construct classes, it doesn't matter what Crystal does. It's fundamentally antithetical to my needs. (JavaScript isn't, but JavaScript is kind of clunky.) I have Kotlin, C#, C++, and Rust if I need static typing. Ruby is for when I don't.
Earlier quoted context omitted.
Have you used a recent (2017) version of Crystal? Quickly building fluent-feeling libraries and tools is exactly my use case for Crystal. For me, everything that Ruby is valuable for is retained. I'm able to do all the things I did in Ruby just fine, and it prevents me from doing a lot of things I shouldn't have been doing. We recently migrated our app from Rails to Crystal (using the Amber framework) and our code ba…
Until I can perform runtime define_method calls and dynamically construct classes, it doesn't matter what Crystal does. It's fundamentally antithetical to my needs. (JavaScript isn't, but JavaScript is kind of clunky.) I have Kotlin, C#, C++, and Rust if I need static typing. Ruby is for when I don't.
Earlier quoted context omitted.
Until I can perform runtime define_method calls and dynamically construct classes, it doesn't matter what Crystal does. It's fundamentally antithetical to my needs. (JavaScript isn't, but JavaScript is kind of clunky.) I have Kotlin, C#, C++, and Rust if I need static typing. Ruby is for when I don't.
How late at runtime do these dynamic definitions need to be possible? Just at startup or also after the program has been running for a while? I occasionally wonder whether it might be possible to accommodate more dynamic language features with a compiler that treats them like a macro system that is expanded statically, such that no actual dynamicism is necessary at runtime.
Or just use Crystal https://crystal-lang.org XD
Crystal is not a replacement for Ruby. In the same way that many Algol-like languages are not a straight swap for each other. Don't get me wrong, Crystal is a nice idea but say goodbye to all that yummy Ruby meta-programming which is one of the key things what makes the language so appealing in the first place.