Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby vs. Crystal Performance

ptimofeev.com

Post reply on HN
Print view View original

131–140 of 151 posts

Re: Ruby vs. Crystal Performance

#131

Post by iomcr »

tluyben2 wrote: post #127
bovermyer wrote: post #33

Coming at Crystal from a Go and PHP development background, here are my thoughts: - The syntax is lovely. No, really. - I hate waiting for it to compile, especially compared to Go's compile time. - It's really young yet, and the ecosystem is just getting started.

> - The syntax is lovely. No, really. Matter of taste; I find it horrible, just as I find Ruby syntax horrible. And I do not care about syntax too much generally (among my production langs are k and clojure) but I find this an eye sore; don’t know why but it is what it is. Edit: aaah downvotes for an opinion :) Anyway, background; I maintained a huge Rails codebase for years; it was pretty much the worst thing I ever…

Ruby syntax's alleged beauty is one one of its most popular features and you're in a thread about a language that intentionally copied that feature.

Re: Ruby vs. Crystal Performance

#132

Post by machiaweliczny »

chrisseaton wrote: post #28
watzon wrote: post #27

Earlier quoted context omitted.

Care to explain more? Having been using Ruby for about 8 years and Crystal for about 4, they actually have an extremely similar syntax and are also semantically very close. To the point where many Ruby scripts are completely valid Crystal, or at the very least require only a few changes. I do think that people trying to compare Crystal to Ruby kind of miss the point though. Ruby as an interpreted language, even optim…

> Care to explain more? Having been using Ruby for about 8 years and Crystal for about 4, they actually have an extremely similar syntax and are also semantically very close. To the point where many Ruby scripts are completely valid Crystal, or at the very least require only a few changes. It doesn't have Kernel#eval. It doesn't have Kernel#send. It doesn't have Kernel#binding. It doesn't has Proc#binding. It doesn't…

I programmed a little in Ruby and IMO all this dynamic stuff is redundant(to be polite).

Re: Ruby vs. Crystal Performance

#133

Post by jiofih »

gavinray wrote: post #88
hosh wrote: post #65

Earlier quoted context omitted.

However, JS does not treat everything as an object as pervasively as Ruby does. A JS object and a JS integer are two different abstract data types. A Ruby number literal "1" is treated as an object of the Integer class. There are no separate abstract data type other than an object. All operators for an Integer can be overriden (in runtime), or perhaps, a specific object's methods can be overridden. Now granted, the r…

A JS integer is actually an instance of the "Number" object, you can to a small degree alter fundamental behavior even with primitive types

No it is not. It is a primitive, this difference is well defined in the ECMAScript spec. Same for strings. An instanceof String is strictly not the same as a string primitive (and there are runtime consequences).

Re: Ruby vs. Crystal Performance

#134

Post by _v7gu »

gavinray wrote: post #88
hosh wrote: post #65

Earlier quoted context omitted.

However, JS does not treat everything as an object as pervasively as Ruby does. A JS object and a JS integer are two different abstract data types. A Ruby number literal "1" is treated as an object of the Integer class. There are no separate abstract data type other than an object. All operators for an Integer can be overriden (in runtime), or perhaps, a specific object's methods can be overridden. Now granted, the r…

A JS integer is actually an instance of the "Number" object, you can to a small degree alter fundamental behavior even with primitive types

You need to enclose numbers to access the prototype: 1.toString is undefined, whereas (1).toString() is "1"

Re: Ruby vs. Crystal Performance

#135

Post by devmunchies »

ryan-allen wrote: post #116
devmunchies wrote: post #43

Neat seeing crystal on here. I built my startup using crystal and now I write crystal full time. I’m still only using a single dedicated server with a SQLite database.

Full time? Awesome! What is your start up? Are you using a framework? Please tell us more :)

We are a delivery-only cookie company. We process orders online and have lots of bakers/drivers delivering thousands of cookies a week, locally. The backend system processing orders, managing orders records and customers (ERP/CRM), and assigning to drivers is all Crystal on the backend. We started almost 2 years ago and the coronavirus really validated our business model. We don't use any 3rd party delivery services like doordash so our drivers can do 4-6 orders per hour.

No frameworks. the only external crystal dependencies are: sqlite3, awscr-s3, and jwt.

I was using just crystal template views (ECR) on the frontend but its not maintainable or advanced enough so I'm slowly transitioning everything to Preact.

https://cravecookie.com

Re: Ruby vs. Crystal Performance

#136

Post by megavolcano »

kimburgess wrote: post #84
megavolcano wrote: post #80

Huge ruby ran here. Ruby on Rails has been my day job for a decade, and it pays the bills well enough. Crystal has always been a curiosity to me, but I have never been as productive in any other language or framework as I have been with Rails. I dont' care if you're language is "ruby-like" or "go fast" - if I'm not as productive with it as I am with Ruby, I'm not gonna touch it. Get back to me when there is Crystal o…

Here you go: https://spider-gazelle.net/

Does it also have a massive community and thousands of libraries(rubygems) for almost every possible thing you can possibly think of?

Re: Ruby vs. Crystal Performance

#137

Post by bovermyer »

tluyben2 wrote: post #127
bovermyer wrote: post #33

Coming at Crystal from a Go and PHP development background, here are my thoughts: - The syntax is lovely. No, really. - I hate waiting for it to compile, especially compared to Go's compile time. - It's really young yet, and the ecosystem is just getting started.

> - The syntax is lovely. No, really. Matter of taste; I find it horrible, just as I find Ruby syntax horrible. And I do not care about syntax too much generally (among my production langs are k and clojure) but I find this an eye sore; don’t know why but it is what it is. Edit: aaah downvotes for an opinion :) Anyway, background; I maintained a huge Rails codebase for years; it was pretty much the worst thing I ever…

For what it's worth, I thought your comment was reasonable given the discussion and upvoted it.

You're allowed to hate Crystal's syntax. I'd be curious to hear why, though.

Re: Ruby vs. Crystal Performance

#138

Post by nullmage »

devmunchies wrote: post #43

Neat seeing crystal on here. I built my startup using crystal and now I write crystal full time. I’m still only using a single dedicated server with a SQLite database.

I'm really curious why you picked Crystal for your startup :) Currently I'm evaluating different stacks and so far Crystal and Elixir are the ones that stand out the most. Did you evaluate other languages and frameworks before settling on Crystal? What has been your biggest pain points so far with the language / ecosystem? Would love to hear more :)

Re: Ruby vs. Crystal Performance

#139

Post by nickbauman »

nine_k wrote: post #61
nickbauman wrote: post #30

Earlier quoted context omitted.

Yeah how fast is that compiler? If it's just another compiled language (rather than the kind of wicked fast compiled language like Go), my enthusiasm will be dampened...

If it has reasonable incremental compilation, it can take a few seconds to compile. With good code structure, I see large Java projects compile small changes in seconds, even though compiling Java used to be a hog. You don't often rebuild from scratch during development, do you?

Often I do because that's what CI does. This is pretty normal.

But the point is having a different view of what compilation means in the developer's workflow as a language designer. Having the engineer have to think about how to organize the code for the compiler is bad design unless that organization is built into the compiler. The compiler should reject programs that are not organized for optimal compilation. And the organization required at least does not impede understanding of the code (best if it improves it). This is Go's design imprimatur and it's critically important to the success of Go.

FWIW, I see large Java projects compile small changes take minutes to compile, even using hot-reload tools.

Figwheel in Clojure is not like this, however: they're doing something right there.

Re: Ruby vs. Crystal Performance

#140

Post by nickbauman »

nine_k wrote: post #114
abeppu wrote: post #98

Earlier quoted context omitted.

I often switch between feature branches, when working on more than one project in a repo with multiple related modules. If there's a change near the top of that dependency graph, I'm forced to not exactly rebuild from scratch, but still to rebuild quite a lot.

Right now I'm at the very same situation. Yes, it is frustrating. This is why things close to the top of the dependency graph should be small, well-tested, and rarely need changes. But when you still need to troubleshoot them, there's no way around recompiling a lot of stuff if you want these static guarantees :(

Bad language design, IMO. The language shouldn't make the writers in it worry about how to organize the code to speed up the compiler.
Post reply on HN