11 ms·

I've always been fascinated by this phenomenon, which one can also see in the Lua and Python communities: Use a language whose natural implementation is extreme

I've always been fascinated by this phenomenon, which one can also see in the Lua and Python communities: Use a language whose natural implementation is extremely slow, and then invest enormous amounts of time and effort to make it fast. Why not just use a language whose natural implementation is already pretty fast? While I understand the value of some dynamic language features, many of the features of dynamic languages that are hardest to make fast are undesirable in any code base larger than a 50 line script anyway.

0des 4y ago
walmart and a few others did this with node back in the 0.10 days, except iirc it was them that was holding up node at that version. iirc when iojs forked off, they had a much faster release schedule, and then at some point rejoined the main node project which then proceeded at a much faster rate. Was it also nike and paypal? I remember it being walmart and some others that were big champions of node in the beginning.
- bin_bash 4y ago
  > iirc it was them that was holding up node at that version really? I thought it was Joyent? Would love a source on this.
  - 0des 4y ago
    yeah sorry about that, thats just off the top of my head. it was a wild time for me, so the events happening at the time coincided with me reading about the whole debacle live as iojs was happening.
russtrotter 4y ago
Yours is a fair question. Theories: * Cheaper to invest in your tools than overhauling your people/codebases/etc * Sense of wanting to give back to your core tooling * The decision maker(s) for the investment just really love Ruby?
- politician 4y ago
  Theory #4: The performance is actually fine, but the developers were given a project to improve performance in order to keep them around for hot fixes in a codebase they know well and to mentor junior employees.
vorpalhex 4y ago
This is why we have C bindings. Let performance things be performant and readable things be readable.
- pjmlp 4y ago
  And in the process add a couple of CVEs...
  - vorpalhex 4y ago
    You don't need to stay in C. You can pop through to Rust or Golang or what have you.
    - pjmlp 4y ago
      Which begs the point why use Ruby at all, plenty of AOT/JIT languages with great IDE tooling to chose from.
      - bin_bash 4y ago
        You think Shopify should've written their backend in Rust? I really wonder if people saying this have ever used Rust. Ruby is great for developers of all skill to learn and be productive. Rust is fast as the devil but you have to be a damn good coder to learn it. Even then I doubt you can be as productive managing memory all the damn time. It's a low-level language great at low-level things. Ruby is a great option for Shopify. Rust is a great option for Firefox's Servo (though that project failed so maybe not).
        pjmlp 4y ago
        Where does "Plenty of AOT/JIT languages" imply Rust?
        bin_bash 4y ago
        reading my comment from yesterday I don't know what I was thinking, apologies
mountainriver 4y ago
Yeah it’s an interesting point. Wrt Python, I’ve tried writing ML in many different languages for this exact reason, but at the end of the day community is everything. Pythons community in the ML space is pretty incredible. Trying to recreate all the libraries in another language is no small task, then you also have the issue that Data Scientists don’t want to write in complex languages. In events like this, improving the language can start to look like the best option.
- skrtskrt 4y ago
  Agreed, as someone who has largely done web services in Python, along with some data engineering I work professionally in Golang now and I appreciate so many things about it, but when I go back to get something done for a personal project in Python, it is scary how much faster I can move. Pydantic, FastAPI, SQLAlchemy, Alembic, requests, attrs, click... it's going to be a long time before other languages can hope to provide libraries with developer experiences that even come close.
zrail 4y ago
Shopify was founded in 2006 and I'm sure (having never worked there) there are things in their codebase that are that old. What were the options in 2006 for languages with both a fast runtime and reasonable DX? I honestly can't think of any. Ruby at the time was pretty far ahead on DX for mainstream and up and coming languages. It was known to be slow but DX for Java was really not great and mired in "enterprise" features and mindset. Edit: python was of course around and I don't remember the Django timeline well enough to say if it was viable in 2006 or not. PHP was of course around but again there was a mindset issue at the time.
- cultofmetatron 4y ago
  cough common lisp cough
  - zrail 4y ago
    Sure. Not exactly mainstream so one would need to consider the hiring pipeline, but if it serves as a competitive advantage then sure.
    - cultofmetatron 4y ago
      it was used to write viaweb back in the 90's. The original saas that made Ycombinator possible.
      - zrail 4y ago
        Ok but that still doesn't make it mainstream or have a candidate pool. If those things don't matter then anything goes.
        closeparen 4y ago
        An underrated feature of obscure languages is that they alienate people who think “$tool developer” is a an identity.
    - 4y ago
bin_bash 4y ago
I don't think "fast" languages are automatically better, they have downsides for sure: * Rust - I do not understand the borrow checker at all and I'm a senior engineer at FAANG. I can barely write a simple function in Rust. I've struggled more learning Rust than any language (and I can write C and C++ just fine!) * Go - I like Go, but there is a ton of boilerplate involved with writing it. Ruby is far more concise and you can get straight to business logic. * Java - Even more boilerplate * C/C++ - I think Ruby clearly wins on productivity here
- mosen 4y ago
  What about C#? That being said, I might just be accustomed to all the boilerplate.
  - bin_bash 4y ago
    Biggest downside is you're likely committing yourself to the Microsoft stack and a single vendor for most of your technology. I don't think it's necessarily the wrong decision but you have to decide if it's right for your project.
    - seabrookmx 4y ago
      Dotnet core runs fine in Docker/on Linux? Most C# apps I've worked on in the last 5 years are deployed to Kubernetes.
      - bin_bash 4y ago
        fair enough, perhaps I should give it another look
    - GiorgioG 4y ago
      100% inaccurate/outdated (by 5 years) info. I've run .NET Core applications on Linux/Docker/K8s + Postgres. The only Microsoft 'stack' there is .NET itself.
0x008 4y ago
Because management want's to "get things done" and quickly "evaluate ideas", a dynamic and somewhat loose language is actually an advantage in prototyping. Also it is very easy to find new developers than for example if you'd use rust, because you can just hire any frontend dev. tooling can be built with money and money is usually not the issue for these companies.
- carlivar 4y ago
  Precisely. Twitter is a great example of this. I'm sure they have moved beyond Ruby in many areas but it was originally core and got them off the ground quickly, I presume.
  - kaba0 4y ago
    Isn’t twitter running on Scala with Graal nowadays?
- pizza234 4y ago
  Splitting services and porting them to a faster language doesn't prevent prototyping in the main, slower, language (in this case, Ruby). It also doesn't need to be microservices madness - see GitLab (and also GitHub, but I think they don't open source their internal services), which rewrote some parts in Go.
- pjmlp 4y ago
  Dynamic and somewhat loose language doesn't preclude not having at very least JIT support out of the box, even BASIC was better in that regard. And if we take into account Ruby's predecessors, Smalltalk, SELF, Dylan.
  - rileyphone 4y ago
    SELF was really fast, at least as claimed [0] - about half the speed of optimized C and quicker to compile. It was where the HotSpot tech for the JVM came from, and V8 uses a similar object model and thus techniques. Just wish they could have made it usable! [0] https://bibliography.selflanguage.org/practical.html https://bibliography.selflanguage.org/practical.html
pull_my_finger 4y ago
I think Lua is catching a stray here. For most uses, Lua, even the PUC-Rio/vanilla implementation, is pretty fast. LuaJIT is quite fast. And because Lua is an embedded language authors can defer to C or whatever the host language is for bottlenecks requiring more speed. IDK if people are seeking dynamic types specifically, but it sure is nice to have stuff like memory management + easy string manipulation built-in sometimes.
- w1nk 4y ago
  Lua definitely caught a stray here. The reference VM is pretty fast, the JIT is just way faster. No idea how Lua ended up wrapped in the conversation with Python...
- rurban 4y ago
  Lua has no OO, and changes its stdlib all the time.
  - wink 4y ago
    I have no idea what you're alluding to. Not only are many people on LuaJIT's api version anyway, I don't remember ever running into any meaningful stdlib change that wasn't easily fixed. And Lua not having OO isn't really a problem to most people either.
yowlingcat 4y ago
What does fast "natural implementations" mean? Runtime? Compile-time? Because if one sacrifices the latter for the former, I think that skirts over the main benefit. With dynamic, interpreted languages that have effectively zero compile-time, one can achieve significantly tighter iteration cycles across a team, ending up limited more by test suite runtime than by slow edit/recompile cycles. This leads to higher productivity across an engineering organization with a quickly evolving codebase. Not important for all use cases, but pretty critical for many.
- kaba0 4y ago
  > effectively zero compile-time, one can achieve significantly tighter iteration cycles across a team I don’t know what machines do people develop on, but on a fairly old laptop I get practically instantaneous iteration with incremental compiles with Rust, which is one of the slowest compiling languages. I honestly can’t imagine where is this supposed slow compiles in case of something like Java - like sure one can create some monstrosity of a build definition, but if some competent person wrote it it is just as fast as an interpreted language. Hell, it can do hot swapping just fine.
wmfiv 4y ago
Because you already have a $50B business that runs on the slow thing. So from a risk and cost/benefit analysis making the slow thing fast sounds a lot better than "rewrite everything".
- mike_hock 4y ago
  More importantly, you had to hack shit together as fast as possible to get a dice roll at the $50B business or bust game.
yen223 4y ago
A better question to ask is, why are these "slow" languages winning? If performance is as important as we think it is, why don't we see startups using Rust or whatever just running circles around startups using Ruby? The answer to this will lead to what actually matters in a language, in terms of building a product. Raw performance isn't it.
- clpm4j 4y ago
  One plausible reason in my mind is that startups tend to hire devs on the younger side, and it seems (from my perspective in the USA) that most new-ish grads come out of school having done most of their programming in Python. Plus some Javascript if they've dabbled in web dev building hobby projects.
  - hw 4y ago
    Ruby/Rails optimizes for developer productivity. Once you prove yourself as a company and your product reaches a scale where you cant just throw $$$ at the problem, you’d be in a good spot to then hire folks to start rewriting parts in $languageofchoice.
  - pjmlp 4y ago
    40 years ago those newly hires would have only learned BASIC. Except at least BASIC had compilers available, and Darthmound BASIC was originally designed with what we call JIT nowadays, even if that wasn't a thing on 8 bit home computers.
- nickjj 4y ago
  This is something I've thought a lot about over the years too. Runtime performance is great and very much welcome if you can get it for free but for a ton of web apps it's not a major selling point on its own. If I can write 30-100% less code and be able to Google almost every single problem I encounter and find tons of high quality blog posts, documentation and videos along with having decently maintained third party libraries for common features then this is going to win every time in my book against something that doesn't have this. It doesn't matter if your web app uses 100mb of memory instead of 1gb or can serve 300 requests per second instead of 30. Most apps never come remotely near the point where this level of performance matters and Rails makes it easy enough to cache things where you can get your p95+ responses responding in 50-100ms or less without much effort. Basically Rails sets you up where a solo dev or small team can run an entire SAAS app on a single $20-40 / month server and have tens of thousands of paying customers without really having to think much about performance. Combine this with Hotwire and you can build really nice feeling sites very quickly if you're the type of person who doesn't want to build APIs + JS front-ends. On the other side of the spectrum with Shopify, GitHub and Basecamp you have engineers running Rails at massive scale making the framework better for everyone (themselves included). It's a self-fulfilling prophecy and win / win scenario because the more people that use it contribute back to the project (patches, community related things, etc.). At this point the only things that matter are fast how you can build your app and how happy are you building / maintaining it. As Ruby, Rails and compute resources get faster then frameworks who focus mainly on performance become less appealing over time for a huge class of web apps because once you reach "good enough" performance it's all about the community and mass adoption. It's like a company who pops up and tries to copy another company but adds 1 small feature to differentiate themselves. As soon as the company you copied decides to add that feature you're going to be climbing way up hill to barely survive.
UncleOxidant 4y ago
Also, if they want a faster Ruby why not invest in Crystal? https://crystal-lang.org/ https://crystal-lang.org/
gregors 4y ago
Ruby is a helluva lot of fun and a lot of engineers at Shopify like it. Life isn't just about taking the shortest route sometimes. One of my favorite quotes > I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more. Alan J. Perlis
rsanek 4y ago
The thing is, interpreted languages have a natural advantage vs. more performant, compiled ones when it comes to iteration speed (and also often ease of early deployment). I think the reason we see this is that while it would be great to pick a more performant language at the beginning, it may mean that your iteration speed is too slow and you simply don't survive as a company (run out of funding, can't pivot fast enough, etc.) In my mind, it's actually a very reasonable choice to start with what you think will be the most optimized for early developer productivity. Once you get to be a company worth tens of billions, you can just pay people to solve this problem for you.
scelerat 4y ago
Time-to-market with a viable product is extremely important. In the case of Rails in particular, the developer experience is such that even a very green programmer (for example, an entrepreneur who has taken a class or two) can bootstrap a working proof of concept quickly. That alone can be worth whatever drawbacks the language "speed" is, and is partly why Rails (and python stacks) were and continue to be popular. Also, language speed alone isn't a deciding factor if your bottlenecks are elsewhere: network latency, i/o etc. Having a "fast" language, for many projects, is something you worry about only after achieve some kind of success, and that success is made more achievable by having good developer tools.
itsTyrion 4y ago
I mean for Lua we at least have LuaJIT which is pretty fast. But Ruby?

0des 4y ago

walmart and a few others did this with node back in the 0.10 days, except iirc it was them that was holding up node at that version. iirc when iojs forked off, they had a much faster release schedule, and then at some point rejoined the main node project which then proceeded at a much faster rate. Was it also nike and paypal? I remember it being walmart and some others that were big champions of node in the beginning.

bin_bash 4y ago
> iirc it was them that was holding up node at that version really? I thought it was Joyent? Would love a source on this.
- 0des 4y ago
  yeah sorry about that, thats just off the top of my head. it was a wild time for me, so the events happening at the time coincided with me reading about the whole debacle live as iojs was happening.

russtrotter 4y ago

Yours is a fair question. Theories: * Cheaper to invest in your tools than overhauling your people/codebases/etc * Sense of wanting to give back to your core tooling * The decision maker(s) for the investment just really love Ruby?

politician 4y ago
Theory #4: The performance is actually fine, but the developers were given a project to improve performance in order to keep them around for hot fixes in a codebase they know well and to mentor junior employees.

vorpalhex 4y ago

This is why we have C bindings. Let performance things be performant and readable things be readable.

pjmlp 4y ago
And in the process add a couple of CVEs...
- vorpalhex 4y ago
  You don't need to stay in C. You can pop through to Rust or Golang or what have you.
  - pjmlp 4y ago
    Which begs the point why use Ruby at all, plenty of AOT/JIT languages with great IDE tooling to chose from.
    - bin_bash 4y ago
      You think Shopify should've written their backend in Rust? I really wonder if people saying this have ever used Rust. Ruby is great for developers of all skill to learn and be productive. Rust is fast as the devil but you have to be a damn good coder to learn it. Even then I doubt you can be as productive managing memory all the damn time. It's a low-level language great at low-level things. Ruby is a great option for Shopify. Rust is a great option for Firefox's Servo (though that project failed so maybe not).
      - pjmlp 4y ago
        Where does "Plenty of AOT/JIT languages" imply Rust?
        bin_bash 4y ago
        reading my comment from yesterday I don't know what I was thinking, apologies

mountainriver 4y ago

Yeah it’s an interesting point. Wrt Python, I’ve tried writing ML in many different languages for this exact reason, but at the end of the day community is everything. Pythons community in the ML space is pretty incredible. Trying to recreate all the libraries in another language is no small task, then you also have the issue that Data Scientists don’t want to write in complex languages. In events like this, improving the language can start to look like the best option.

skrtskrt 4y ago
Agreed, as someone who has largely done web services in Python, along with some data engineering I work professionally in Golang now and I appreciate so many things about it, but when I go back to get something done for a personal project in Python, it is scary how much faster I can move. Pydantic, FastAPI, SQLAlchemy, Alembic, requests, attrs, click... it's going to be a long time before other languages can hope to provide libraries with developer experiences that even come close.

zrail 4y ago

Shopify was founded in 2006 and I'm sure (having never worked there) there are things in their codebase that are that old. What were the options in 2006 for languages with both a fast runtime and reasonable DX? I honestly can't think of any. Ruby at the time was pretty far ahead on DX for mainstream and up and coming languages. It was known to be slow but DX for Java was really not great and mired in "enterprise" features and mindset. Edit: python was of course around and I don't remember the Django timeline well enough to say if it was viable in 2006 or not. PHP was of course around but again there was a mindset issue at the time.

cultofmetatron 4y ago
cough common lisp cough
- zrail 4y ago
  Sure. Not exactly mainstream so one would need to consider the hiring pipeline, but if it serves as a competitive advantage then sure.
  - cultofmetatron 4y ago
    it was used to write viaweb back in the 90's. The original saas that made Ycombinator possible.
    - zrail 4y ago
      Ok but that still doesn't make it mainstream or have a candidate pool. If those things don't matter then anything goes.
      - closeparen 4y ago
        An underrated feature of obscure languages is that they alienate people who think “$tool developer” is a an identity.
  - 4y ago

bin_bash 4y ago

I don't think "fast" languages are automatically better, they have downsides for sure: * Rust - I do not understand the borrow checker at all and I'm a senior engineer at FAANG. I can barely write a simple function in Rust. I've struggled more learning Rust than any language (and I can write C and C++ just fine!) * Go - I like Go, but there is a ton of boilerplate involved with writing it. Ruby is far more concise and you can get straight to business logic. * Java - Even more boilerplate * C/C++ - I think Ruby clearly wins on productivity here

mosen 4y ago
What about C#? That being said, I might just be accustomed to all the boilerplate.
- bin_bash 4y ago
  Biggest downside is you're likely committing yourself to the Microsoft stack and a single vendor for most of your technology. I don't think it's necessarily the wrong decision but you have to decide if it's right for your project.
  - seabrookmx 4y ago
    Dotnet core runs fine in Docker/on Linux? Most C# apps I've worked on in the last 5 years are deployed to Kubernetes.
    - bin_bash 4y ago
      fair enough, perhaps I should give it another look
  - GiorgioG 4y ago
    100% inaccurate/outdated (by 5 years) info. I've run .NET Core applications on Linux/Docker/K8s + Postgres. The only Microsoft 'stack' there is .NET itself.

0x008 4y ago

Because management want's to "get things done" and quickly "evaluate ideas", a dynamic and somewhat loose language is actually an advantage in prototyping. Also it is very easy to find new developers than for example if you'd use rust, because you can just hire any frontend dev. tooling can be built with money and money is usually not the issue for these companies.

carlivar 4y ago
Precisely. Twitter is a great example of this. I'm sure they have moved beyond Ruby in many areas but it was originally core and got them off the ground quickly, I presume.
- kaba0 4y ago
  Isn’t twitter running on Scala with Graal nowadays?
pizza234 4y ago
Splitting services and porting them to a faster language doesn't prevent prototyping in the main, slower, language (in this case, Ruby). It also doesn't need to be microservices madness - see GitLab (and also GitHub, but I think they don't open source their internal services), which rewrote some parts in Go.
pjmlp 4y ago
Dynamic and somewhat loose language doesn't preclude not having at very least JIT support out of the box, even BASIC was better in that regard. And if we take into account Ruby's predecessors, Smalltalk, SELF, Dylan.
- rileyphone 4y ago
  SELF was really fast, at least as claimed [0] - about half the speed of optimized C and quicker to compile. It was where the HotSpot tech for the JVM came from, and V8 uses a similar object model and thus techniques. Just wish they could have made it usable! [0] https://bibliography.selflanguage.org/practical.html https://bibliography.selflanguage.org/practical.html

pull_my_finger 4y ago

I think Lua is catching a stray here. For most uses, Lua, even the PUC-Rio/vanilla implementation, is pretty fast. LuaJIT is quite fast. And because Lua is an embedded language authors can defer to C or whatever the host language is for bottlenecks requiring more speed. IDK if people are seeking dynamic types specifically, but it sure is nice to have stuff like memory management + easy string manipulation built-in sometimes.

w1nk 4y ago
Lua definitely caught a stray here. The reference VM is pretty fast, the JIT is just way faster. No idea how Lua ended up wrapped in the conversation with Python...
rurban 4y ago
Lua has no OO, and changes its stdlib all the time.
- wink 4y ago
  I have no idea what you're alluding to. Not only are many people on LuaJIT's api version anyway, I don't remember ever running into any meaningful stdlib change that wasn't easily fixed. And Lua not having OO isn't really a problem to most people either.

yowlingcat 4y ago

What does fast "natural implementations" mean? Runtime? Compile-time? Because if one sacrifices the latter for the former, I think that skirts over the main benefit. With dynamic, interpreted languages that have effectively zero compile-time, one can achieve significantly tighter iteration cycles across a team, ending up limited more by test suite runtime than by slow edit/recompile cycles. This leads to higher productivity across an engineering organization with a quickly evolving codebase. Not important for all use cases, but pretty critical for many.

kaba0 4y ago
> effectively zero compile-time, one can achieve significantly tighter iteration cycles across a team I don’t know what machines do people develop on, but on a fairly old laptop I get practically instantaneous iteration with incremental compiles with Rust, which is one of the slowest compiling languages. I honestly can’t imagine where is this supposed slow compiles in case of something like Java - like sure one can create some monstrosity of a build definition, but if some competent person wrote it it is just as fast as an interpreted language. Hell, it can do hot swapping just fine.

wmfiv 4y ago

Because you already have a $50B business that runs on the slow thing. So from a risk and cost/benefit analysis making the slow thing fast sounds a lot better than "rewrite everything".

mike_hock 4y ago
More importantly, you had to hack shit together as fast as possible to get a dice roll at the $50B business or bust game.

yen223 4y ago

A better question to ask is, why are these "slow" languages winning? If performance is as important as we think it is, why don't we see startups using Rust or whatever just running circles around startups using Ruby? The answer to this will lead to what actually matters in a language, in terms of building a product. Raw performance isn't it.

clpm4j 4y ago
One plausible reason in my mind is that startups tend to hire devs on the younger side, and it seems (from my perspective in the USA) that most new-ish grads come out of school having done most of their programming in Python. Plus some Javascript if they've dabbled in web dev building hobby projects.
- hw 4y ago
  Ruby/Rails optimizes for developer productivity. Once you prove yourself as a company and your product reaches a scale where you cant just throw $$$ at the problem, you’d be in a good spot to then hire folks to start rewriting parts in $languageofchoice.
- pjmlp 4y ago
  40 years ago those newly hires would have only learned BASIC. Except at least BASIC had compilers available, and Darthmound BASIC was originally designed with what we call JIT nowadays, even if that wasn't a thing on 8 bit home computers.
nickjj 4y ago
This is something I've thought a lot about over the years too. Runtime performance is great and very much welcome if you can get it for free but for a ton of web apps it's not a major selling point on its own. If I can write 30-100% less code and be able to Google almost every single problem I encounter and find tons of high quality blog posts, documentation and videos along with having decently maintained third party libraries for common features then this is going to win every time in my book against something that doesn't have this. It doesn't matter if your web app uses 100mb of memory instead of 1gb or can serve 300 requests per second instead of 30. Most apps never come remotely near the point where this level of performance matters and Rails makes it easy enough to cache things where you can get your p95+ responses responding in 50-100ms or less without much effort. Basically Rails sets you up where a solo dev or small team can run an entire SAAS app on a single $20-40 / month server and have tens of thousands of paying customers without really having to think much about performance. Combine this with Hotwire and you can build really nice feeling sites very quickly if you're the type of person who doesn't want to build APIs + JS front-ends. On the other side of the spectrum with Shopify, GitHub and Basecamp you have engineers running Rails at massive scale making the framework better for everyone (themselves included). It's a self-fulfilling prophecy and win / win scenario because the more people that use it contribute back to the project (patches, community related things, etc.). At this point the only things that matter are fast how you can build your app and how happy are you building / maintaining it. As Ruby, Rails and compute resources get faster then frameworks who focus mainly on performance become less appealing over time for a huge class of web apps because once you reach "good enough" performance it's all about the community and mass adoption. It's like a company who pops up and tries to copy another company but adds 1 small feature to differentiate themselves. As soon as the company you copied decides to add that feature you're going to be climbing way up hill to barely survive.

UncleOxidant 4y ago

Also, if they want a faster Ruby why not invest in Crystal? https://crystal-lang.org/ https://crystal-lang.org/

gregors 4y ago

Ruby is a helluva lot of fun and a lot of engineers at Shopify like it. Life isn't just about taking the shortest route sometimes. One of my favorite quotes > I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more. Alan J. Perlis

rsanek 4y ago

The thing is, interpreted languages have a natural advantage vs. more performant, compiled ones when it comes to iteration speed (and also often ease of early deployment). I think the reason we see this is that while it would be great to pick a more performant language at the beginning, it may mean that your iteration speed is too slow and you simply don't survive as a company (run out of funding, can't pivot fast enough, etc.) In my mind, it's actually a very reasonable choice to start with what you think will be the most optimized for early developer productivity. Once you get to be a company worth tens of billions, you can just pay people to solve this problem for you.

scelerat 4y ago

Time-to-market with a viable product is extremely important. In the case of Rails in particular, the developer experience is such that even a very green programmer (for example, an entrepreneur who has taken a class or two) can bootstrap a working proof of concept quickly. That alone can be worth whatever drawbacks the language "speed" is, and is partly why Rails (and python stacks) were and continue to be popular. Also, language speed alone isn't a deciding factor if your bottlenecks are elsewhere: network latency, i/o etc. Having a "fast" language, for many projects, is something you worry about only after achieve some kind of success, and that success is made more achievable by having good developer tools.

itsTyrion 4y ago

I mean for Lua we at least have LuaJIT which is pretty fast. But Ruby?