Is ToroPHP gone for good?

[puntofisso]

Admittedly, not a bug/code issue. But I'd be curious to hear what happened, and if the original team suggests alternatives. (Interestingly, Tornado, the Python framework from which Toro took some inspiration, is still alive).

[martinbean]

Ping @anandkunal

[anandkunal]

Greetings! I don't have a long-winded narrative to share other than the following:

• I developed Toro when I was working at a startup that was using PHP. I was inspired by Ruby frameworks like Sinatra - wanting something simple and easy to do dependency injection and static analysis. I got what I was after and opened it up to the world a decade plus ago.

• Over time, there have been patches and updates but nothing earth-shattering. Toro was designed to be simple and accomplish narrow goals. At one point I thought about evolving it into a batteries included framework but never got around to it.

• Over the years, I've dabbled with PHP but have largely shifted my day-to-day to the Go programming language (started a company in 2013 that relied heavily on Go for web/APIs/microservices). For specific reasons, Go was selected over PHP (happy to go into the why if people are curious).

• I still use Toro for weekend hobby projects. To me, PHP is a fantastic language to quickly sketch and prototype ideas. I've had a few ideas for what could be improved upon but haven't implemented anything.

I'm still here and would love to connect with some of you around ideas and where we could take Toro. If folks want to connect over Zoom, let's set something up to chat live.

[puntofisso]

Thanks for the brilliant answer @anandkunal.

And yes, would be curious to hear about the Go vs PHP choice (performance? scalability?), but fundamentally I was just curious to know – I've found Toro a perfect choice for a number of small projects, used Laravel for slightly more complex projects (but with performance caveats – I'm not a professional developer, btw, most of my software developing is for prototyping that then others bring into production).

If you think there's a future for Toro, I'd be happy to hear and discuss, but probably I'm not at a level of contributing to it :)

[anandkunal]

Caveat - I'm on the go (pun intended) and apologize in advance for thumb typos :-).

First off, I think that Laravel is a great framework - there's lots of power and capabilities in that awesome framework. Personally, I've always battled with frameworks because they eventually get in the way. It's all fine and great when you're making a simple site or if the complexity is low or if you're just getting started. But...

Eventually you might need something custom or you find that middleware gets in the way. Given enough time and project diversity you'll work on, your opinions will collide with the framework's opinions. And that's ok! People change and frameworks change too! My goal with Toro was to simplify routing and let people express themselves in handlers - being allowed to use whatever libraries or technologies they wanted.

Regarding performance, I never let that influence what technology I'm selecting when getting started on a project. Frankly, most projects will never need Facebook-like-scale and need a custom runtime! I tend to focus on "right tool for the right job" and development productivity. I have less time today than 10 years ago - family, work priorities, etc. To me, I want to find a balance of something that allows me to easily express myself (scratch an itch) and be flexible to cover lots of use cases.

There were several things that attracted me to Go:

• Strongly typed - I was getting frustrated with lots of runtime issues (my mistakes when addressing variable names, function names, etc.). The compiler really helps - and Go has a very efficient process for compiling code. Yes, I can still get into a situation where there's a runtime panic - but that's much more manageable (and usually my fault anyways!). Even for bigger projects, like a Terraform provider with thousands of lines of code, I can running make takes less than 15 seconds (running on an old MacBook Pro).

• Language with batteries included - there are lots of great libraries in Go by default. The built in HTTP library can be stretched with some simple middleware and accomplish all of my use cases - AKA, I can get parity with PHP with little effort. Templates are still a sore spot and I miss being able to just "echo" things - but that's a hacker/debugger in me talking! I've gotten used to templating in Go and there's support for stuff like Mustache, etc. if that's your thing.

• Portability - this was painful for me with PHP. Having to get PHP installed, configured, and then installing a connector to a web server (Apache) - it was just a lot of work. I'd sometimes discover inconsistenies with point releases between local/production development (yes, I could have managed this better). With Go, I compile a binary targeted for a specific OS and architecture and it works as expected. I don't need to deal with a runtime or web server. I run a binary that includes all of the things that I care about and it just freaking works. My deployment scripts have been dramatically simplified - I upload a binary to a server and I start it :-). My launch scripts have been simplified as well. Could I have gotten here with PHP - definitely. I just didn't want to go through this process for simple things.

• Language simplicity - Go was simple to learn and didn't have a steep curve. The language is simple - there aren't hundreds of keywords or "tricks" that I would take advantage of. Once you grok concepts like channels and goroutines, building concurrent programs feel less like a Herculean effort and a lot more approachable.

I could go on and on...ultimately it was a personal choice...and like I said above, I still use PHP from time to time because I can sketch a project pretty quickly. Both are perfectly fine tools.

[puntofisso]

That's very interesting @anandkunal. Thanks a lot for sharing!