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.
Like others posted, I definitely meant rust, if we're talking compiled, compile time checked systems languages -- there are only so many recent entries with something new to say in the space.
If we're talking just pure abstraction I think there are a lot of other choice that could have delivered similar improvements in performance for an IO-dependent workload, with better methods of abstraction, ecosystem, and safety -- that choice for me would be Typescript.
[EDIT] Also to note, even as a Haskell zealot I'm not crazy enough to suggest someone choose Haskell as an alternative where Go would have been good enough. I have enough experience with business needs to know that the purity/safety/whatever other benefits of haskell just aren't worth the lack of ecosystem, difficulty in finding developers, and hit to developer speed. Haskell is too far on the spectrum (on various axes) to be the right choice most of the time, and not enough companies have shared how they've outperformed with it to even start the conversation. Haskell is like the mercedes of programming languages -- airbags show up there first, but regular cars get them eventually.
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).
Ah, I see your point. But it could just as easily be made in nearly any language, the difference at the level of “is abstract-able” is meters rather than kilometers.
The problem is that as soon as you need something more than a command line call the engineering burden explodes relative to languages that natively support greater abstraction at the lexical and logical level.
> Ah, I see your point. But it could just as easily be made in nearly any language, the difference at the level of “is abstract-able” is meters rather than kilometers.
True, most languages could do it, but there are some hard stops to how easy it is to abstract in golang, and performance also knocks some languages out.
> The problem is that as soon as you need something more than a command line call the engineering burden explodes relative to languages that natively support greater abstraction at the lexical and logical level.
Agreed, once you're off the happy path things can be many times more painful in Rust than Go. I personally think Go will replace Java in most enterprise-y software shops within 5-10 years. Unless there's a specific reason to use the JVM, Go is more than good enough and it's goals align with industry very well.
I think go would be huge if they could ease their pain points. The average developer isn’t interested in why generics are actually not necessary, or “here’s how you can still use generics” stuff. Even if they’re wrong, you still need to work in that reality.
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.