5 ms·

Looking at such articles makes me feel we are going back in time rather than improving efficiencies for developers to build RESTful server. If you look at Ruby

Looking at such articles makes me feel we are going back in time rather than improving efficiencies for developers to build RESTful server. If you look at Ruby on Rails you can build the server shown here in one min that is scalable and backed with database. I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic.

geodel 6y ago
I think most people are expecting zero traffic so they do not need to waste even one min to write any REST server.
skjfdoslifjeifj 6y ago
He could build it in Go much faster just by using a couple of additional libraries but he's purposely limiting himself to just the standard library for the purpose of these articles. > I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic. If you don't care that's fine, but there are lots of us that do. This is subjective, but I find the memory use and overall performance of Rails/Django/Spring Boot applications to be completely unacceptable and there are far too many breaking changes.
- lenartowski 6y ago
  What languages/framework do you use when performance/memory usage is key?
  - theshrike79 6y ago
    Not OP, but I'd go with Go or a fresh version of .NET Core depending on where it would need to integrate to. If we're talking real time sub-millisecond performance, then Rust.
- ptr 6y ago
  It doesn’t make sense to say Rails etc are “Completely unacceptable” without giving a context. How can it be subjective? Memory is also rather arbitrary, why focus on that and not user friendliness? Or even GPU or cache efficiency? “Breaking changes” might not matter either if what you’re writing is a one-off.
hardwaresofton 6y ago
What you're pointing to is the need for better abstractions and Go is not the language for that (it will be more-so when generics arrive). There is a language that has faster-than-go speed and better abstractions, but HN seems to be somewhat decided on whether they think it's awesome or terrible, and there was recently an blog post on front-page about how it was bad for APIs (which I heavily disagree with but I am biased so I opted not to comment on). Go definitely does have some other web frameworks that make work like this simpler, but on the other hand, people sometimes shy away from those because the stdlib is more universal.
- franklyt 6y ago
  Are you talking about Haskell? That’s a hard sell.
  - scns 6y ago
    He means Rust. https://news.ycombinator.com/item?id=25798008 https://news.ycombinator.com/item?id=25798008
    - franklyt 6y ago
      I was hoping even less that was the case, feels like a very out of touch comment, but I’m willing to listen.
      - hardwaresofton 6y ago
        I don't think I was out of touch (which I guess is always how it goes). The value propositions of Golang and Rust are pretty well understood at this point, and I think that if you want abstraction power the choice between them is clear. Rust is hard, but it's not harder than Haskell, and at a high level of abstraction it can be simpler than Golang has to offer in the stdlib, in the happy path with better results, and more safety. Again, this is the happy path case, but it's not impossible, just hard/unlikely -- Golang on the other hand can never achieve this level of simple interfaces built on abstraction because of the goals and design choices the language has made. The original comment is this: > Looking at such articles makes me feel we are going back in time rather than improving efficiencies for developers to build RESTful server. If you look at Ruby on Rails you can build the server shown here in one min that is scalable and backed with database. I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic. My point was that Rust gives you the tools to write a rails/sinatra (at a glance) library that in the happy/simple path (which most regular CRUD backends are) can be simpler than Golang because the abstractions to make it simple are there, and speed will just about always be the fastest possible relative to quality of underlying code. Golang can (and does) provide similar, but it is always a step behind (on purpose) on the abstraction front. If you're going to provide a carefully crafted interface that is very easy to use, it matters less that rust can have a really high barrier to entry (rails is valuable because you can be productive without being a ruby expert).
ithrow 6y ago
Some prefer clear, flexible easy to debug code instead of coding to 15 layers of abstraction. For an HTTP API you have to discard more than half of Rails anyway.
- qudat 6y ago
  I agree so hard on this. Anyone recommending rails as some sort of elevation of a restful API is puzzling to me. It’s easy to get started for people that don’t want to code. Instead they want to spend all of their time memorizing the cascade of configuration objects where you have to learn the exact phrase to get rails to do what you want it to. I know this is all opinion and I have colleagues who are excellent engineers that prefer rails, but it goes against everything I enjoy about software development.
  - scrose 6y ago
    I wouldn’t call Rails ‘easy to get started’. The learning curve is steep, but once you get over it, you can hop into nearly any Rails application and immediately be able to contribute. I prefer Rails for most things work related for that very reason. Having worked a couple places where Python or Go microservices were hyped up, but every installation, DB schema, and folder structure seemed to be built with a different idea in mind, and or debated, I have a strong appreciation for right standards around convention. Especially when I don’t have to get into debates like whether DB table names should be plural or singular. On the side I really do enjoy working with Go though, and wouldn’t hesitate to use it if it seemed like the right tool for the moment.
  - pm90 6y ago
    I suspect you will see a lot more of rails (and rails like frameworks) being used just because they are so simple to use and beginners can use it without understanding too deeply. Having more people who can understand/build/fix will always win out, and rails is what most coding bootcamp teach. So there’s just going to be too many folks who will choose rails over more suitable languages. I’m not super convinced that’s a bad thing though. The software industry has always suffered a perennial shortage of engineers. What I predict will happen is that an ecosystem of tools will spring up around rails and there will be serious investment in improving performance rather than the framework being abandoned. Remember how kubernetes changed infrastructure development to managing config files? It’s what I see happening to most areas of software development. The more experienced software engineers will then be responsible for optimizing/bug fixing/ scaling.
qudat 6y ago
“Setting up a server” has to happen only once. I’d rather spend a couple days setting something up that I have complete control over rather than using a one-line setup solution that I’ll have to rip out months later.
pjmlp 6y ago
That is the whole ethos of Go community, at least they had something modern like a GC from the get go.
friseurtermin 6y ago
That's literally the point of this article: > There are strong opinions both for and against using frameworks. My goal in these posts is to examine the issue objectively from several angles.
morelisp 6y ago
> I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic. It's not about whether you expect Google-like traffic, but about whether you expect a Google-like ratio of traffic/compute to capacity. My day job doesn't deal with "Google-like" traffic (maybe one Google product's worth of traffic), but we also only have about 10 servers to ingest what we do get. My current side project I expect to deal with even fewer orders of magnitude but I also want to be able to run it on a single server to keep costs and operational overhead low.

geodel 6y ago

I think most people are expecting zero traffic so they do not need to waste even one min to write any REST server.

skjfdoslifjeifj 6y ago

He could build it in Go much faster just by using a couple of additional libraries but he's purposely limiting himself to just the standard library for the purpose of these articles. > I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic. If you don't care that's fine, but there are lots of us that do. This is subjective, but I find the memory use and overall performance of Rails/Django/Spring Boot applications to be completely unacceptable and there are far too many breaking changes.

lenartowski 6y ago
What languages/framework do you use when performance/memory usage is key?
- theshrike79 6y ago
  Not OP, but I'd go with Go or a fresh version of .NET Core depending on where it would need to integrate to. If we're talking real time sub-millisecond performance, then Rust.
ptr 6y ago
It doesn’t make sense to say Rails etc are “Completely unacceptable” without giving a context. How can it be subjective? Memory is also rather arbitrary, why focus on that and not user friendliness? Or even GPU or cache efficiency? “Breaking changes” might not matter either if what you’re writing is a one-off.

hardwaresofton 6y ago

What you're pointing to is the need for better abstractions and Go is not the language for that (it will be more-so when generics arrive). There is a language that has faster-than-go speed and better abstractions, but HN seems to be somewhat decided on whether they think it's awesome or terrible, and there was recently an blog post on front-page about how it was bad for APIs (which I heavily disagree with but I am biased so I opted not to comment on). Go definitely does have some other web frameworks that make work like this simpler, but on the other hand, people sometimes shy away from those because the stdlib is more universal.

franklyt 6y ago
Are you talking about Haskell? That’s a hard sell.
- scns 6y ago
  He means Rust. https://news.ycombinator.com/item?id=25798008 https://news.ycombinator.com/item?id=25798008
  - franklyt 6y ago
    I was hoping even less that was the case, feels like a very out of touch comment, but I’m willing to listen.
    - hardwaresofton 6y ago
      I don't think I was out of touch (which I guess is always how it goes). The value propositions of Golang and Rust are pretty well understood at this point, and I think that if you want abstraction power the choice between them is clear. Rust is hard, but it's not harder than Haskell, and at a high level of abstraction it can be simpler than Golang has to offer in the stdlib, in the happy path with better results, and more safety. Again, this is the happy path case, but it's not impossible, just hard/unlikely -- Golang on the other hand can never achieve this level of simple interfaces built on abstraction because of the goals and design choices the language has made. The original comment is this: > Looking at such articles makes me feel we are going back in time rather than improving efficiencies for developers to build RESTful server. If you look at Ruby on Rails you can build the server shown here in one min that is scalable and backed with database. I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic. My point was that Rust gives you the tools to write a rails/sinatra (at a glance) library that in the happy/simple path (which most regular CRUD backends are) can be simpler than Golang because the abstractions to make it simple are there, and speed will just about always be the fastest possible relative to quality of underlying code. Golang can (and does) provide similar, but it is always a step behind (on purpose) on the abstraction front. If you're going to provide a carefully crafted interface that is very easy to use, it matters less that rust can have a really high barrier to entry (rails is valuable because you can be productive without being a ruby expert).

ithrow 6y ago

Some prefer clear, flexible easy to debug code instead of coding to 15 layers of abstraction. For an HTTP API you have to discard more than half of Rails anyway.

qudat 6y ago
I agree so hard on this. Anyone recommending rails as some sort of elevation of a restful API is puzzling to me. It’s easy to get started for people that don’t want to code. Instead they want to spend all of their time memorizing the cascade of configuration objects where you have to learn the exact phrase to get rails to do what you want it to. I know this is all opinion and I have colleagues who are excellent engineers that prefer rails, but it goes against everything I enjoy about software development.
- scrose 6y ago
  I wouldn’t call Rails ‘easy to get started’. The learning curve is steep, but once you get over it, you can hop into nearly any Rails application and immediately be able to contribute. I prefer Rails for most things work related for that very reason. Having worked a couple places where Python or Go microservices were hyped up, but every installation, DB schema, and folder structure seemed to be built with a different idea in mind, and or debated, I have a strong appreciation for right standards around convention. Especially when I don’t have to get into debates like whether DB table names should be plural or singular. On the side I really do enjoy working with Go though, and wouldn’t hesitate to use it if it seemed like the right tool for the moment.
- pm90 6y ago
  I suspect you will see a lot more of rails (and rails like frameworks) being used just because they are so simple to use and beginners can use it without understanding too deeply. Having more people who can understand/build/fix will always win out, and rails is what most coding bootcamp teach. So there’s just going to be too many folks who will choose rails over more suitable languages. I’m not super convinced that’s a bad thing though. The software industry has always suffered a perennial shortage of engineers. What I predict will happen is that an ecosystem of tools will spring up around rails and there will be serious investment in improving performance rather than the framework being abandoned. Remember how kubernetes changed infrastructure development to managing config files? It’s what I see happening to most areas of software development. The more experienced software engineers will then be responsible for optimizing/bug fixing/ scaling.

qudat 6y ago

“Setting up a server” has to happen only once. I’d rather spend a couple days setting something up that I have complete control over rather than using a one-line setup solution that I’ll have to rip out months later.

pjmlp 6y ago

That is the whole ethos of Go community, at least they had something modern like a GC from the get go.

friseurtermin 6y ago

That's literally the point of this article: > There are strong opinions both for and against using frameworks. My goal in these posts is to examine the issue objectively from several angles.

morelisp 6y ago

> I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic. It's not about whether you expect Google-like traffic, but about whether you expect a Google-like ratio of traffic/compute to capacity. My day job doesn't deal with "Google-like" traffic (maybe one Google product's worth of traffic), but we also only have about 10 servers to ingest what we do get. My current side project I expect to deal with even fewer orders of magnitude but I also want to be able to run it on a single server to keep costs and operational overhead low.