51–60 of 89 posts
I'm surprised he chose to use Martini for the web component since the author himself has chosen to discontinue development of Martini in favor of a different approach with Negroni. These days most people I know that use anything outside of the Golang stdlib seem to reach for Gin.
Odd. RoR and Go address entirely different app domains. The only thing that connects them is that RoR was trendy yesterday, and Go is trendy today. If this is the rationale for replacement, the author will be writing plenty of "replacing" articles in the years forward.
What do you see the app domains of Rails and Go as?
Go is for writing small, focused, paralellizable and likely distributed services. If I wanted to crunch data, I'd try Go.
I'd expect, say, a RoR app to connect to a Go service for some of its heavier domain logic. I'd neither write a RoR-type app in Go, nor a Go-type service in RoR.
I like Ruby/Rails, I like Go. I like frameworks that make your life easier when starting a new project. I don't think Go is anywhere near the list of languages to build a Rails successor on top of. Rails can do so much of the cool stuff it does because Ruby is an incredibly flexible language. Go, on the other hand, could be described as "inflexible as a feature". You have a beautifully simple language that optimizes…
I for one would like to see a serious Go-based alternative to Wordpress. Virtually every major CMS out there uses PHP, and all of them are highly prone to hacking.
This probably has to do with the majority of cheap web hosts out there offering only PHP, Perl, and (if you're really lucky) Rails.
I like Ruby/Rails, I like Go. I like frameworks that make your life easier when starting a new project. I don't think Go is anywhere near the list of languages to build a Rails successor on top of. Rails can do so much of the cool stuff it does because Ruby is an incredibly flexible language. Go, on the other hand, could be described as "inflexible as a feature". You have a beautifully simple language that optimizes…
The idea that programming languages are "worlds apart" and "vastly different" is hyperbole that would make Turing frown or maybe giggle. Have you considered that Ruby is written in C [0], and that you can do plenty of things with a general purpose programming language and some good ideas? Edit: Would you care to substantively explain the downvote(s)? The parent is so preoccupied with frameworks he's overlooking the b…
The fact that Prolog, Fortran and Ruby are all Turing-complete is useful to know from a computer science standpoint, but from a perspective of actual use, it just isn't that relevant. A language — whether human or computer — isn't just about the algorithms it can express, but about the ways it lets you express them, understand them and combine them. And Turing equivalence tells us very little about that sort of thing.
This is a bit abstract, so here's a tiny but concrete example of how differences in how you express an algorithm can have a tangible effect:
f = open("somefile.txt")
f.write("Hello world")
f.close()
with open("somefile.txt") as f:
f.write("Hello world")
So I think it is quite possible for languages to be worlds apart while still being able to compute everything a Turing machine can.
I never personally learned Rails so I'm just an interested observer, but can someone explain the problems with Rails currently? And why the switch in language rather than just making fixes to the framework? After looking through the article it doesn't seem like there was a very strong case made for Go. Thanks!
I like Ruby/Rails, I like Go. I like frameworks that make your life easier when starting a new project. I don't think Go is anywhere near the list of languages to build a Rails successor on top of. Rails can do so much of the cool stuff it does because Ruby is an incredibly flexible language. Go, on the other hand, could be described as "inflexible as a feature". You have a beautifully simple language that optimizes…
The idea that programming languages are "worlds apart" and "vastly different" is hyperbole that would make Turing frown or maybe giggle. Have you considered that Ruby is written in C [0], and that you can do plenty of things with a general purpose programming language and some good ideas? Edit: Would you care to substantively explain the downvote(s)? The parent is so preoccupied with frameworks he's overlooking the b…
Rails is still the best framework for building CRUD applications. It shouldn't be used for every scenario but if you want to build a traditional CRUD app, nothing is better than Rails in my opinion.
I think ASP.NET MVC is as easy as Rails for CRUD apps.
Odd. RoR and Go address entirely different app domains. The only thing that connects them is that RoR was trendy yesterday, and Go is trendy today. If this is the rationale for replacement, the author will be writing plenty of "replacing" articles in the years forward.
What do you see the app domains of Rails and Go as?
Rails works great for things like authentication, creating a nice and maintainable UI, handling billing code, sending emails, managing the database schema, and all the web related stuff.
Erlang and Go work nicely for all the "heavy work", think sending tens of million of push notifications quickly, crunching data etc.
They can communicate using a shared, Rails-maintained database, and things like Redis to trigger updates or orders.
You can even do Erlang-backend processing of Sidekiq payloads, pushed from the Rails side etc.
All in all: use each tool for its own strengths.
Earlier quoted context omitted.
> I just don't see a monolithic web framework being high up on the list of "must haves". And I think that's what makes Go so welcome to many people. In fact, I'm tired of frameworks that do everything for me because they tend to do everything just "well enough". And I noticed the OP is using Martini - which isn't necessarily bad - but it's not needed. It does make learning a language like Go a lot easier for newcomer…
In fact, Go's standard library is fantastic, so you don't need Martini for many things. I think it provides a nice layer on top of the code for comprehensibility when reading through code