[dragonsh]

Probably you might be right, in my view database is just for persistence, most of the time text processing happens in the application or framwwork. Database is a very well understood system so reading and writing to it using language drivers can be optimized. Indeed go and rust both have excellent drivers for PostgreSQL, but still developing web application in them is not easy due to inherent text processing requirements and dealing with http request/response in json, html, xml, protocol buffers, blobs and various mime-types.

[LordHeini]

What text processing? You mean templating? Those a rather well solved problems, although the Go templates are a bit odd.

But Go, Rust, Scala and the like blow those dynamic typed languages out of the water when it comes to APIs.

For example. If you want a number to be a positive integer you would write a Go struct containing a uint. That's all.

Want it to be optional Rust or Scala have an optional Type.

If someone submits a negative number or a float the framework automatically generates an error message.

In ruby for example you would have to write a bunch of validations per hand and a bunch of tests too, to check if those work.

Writing APIs in Go is like half the work compared to Ruby or god forbid PHP.

Have not tries Node yet but i assume it to be on a level with Ruby.

[dragonsh]

It's not a solved problem in rust or go. It's still easier to write understandable text processing code in Python, Perl, Ruby, lisp than in Go or Rust.

Also for web backend Go, Rust cannot close the gap with Python or Ruby or lisp easily. Rust and Go are strong in their own domain writing web backend is not one of them. It does not mean one cannot write, it's just a lot of work.

When dealing with MIME types or REST or HTML or XML etc. dynamic typed languages are still easy, readable with reasonable performance. Only when one wants high performance, will go through the path of writing API in go or rust.

[pts_]

Go is already being used in lots of microservices.

[jashmatthews]

If you’ve got 300 engineers and performance problems then that’s a great idea.

If you have 3 engineers and a little seed funding then building Go microservices to serve a web app is probably just pissing away VC money.

Just because people do it doesn’t make it a good idea.

[zzzcpan]

> If you want a number to be a positive integer you would write a Go struct containing a uint. That's all.

Uint is a specific machine type, not an abstract positive integer type. So if you want a positive integer in Go you are fucked. If you try to use uint for that you have to carefully handle a whole bunch of edge cases. It's only in some dynamically typed languages a positive integer will be a positive integer and in better ones numeric operations will even be separate from string operations, so doing APIs will be significantly safer than in Go.

[jashmatthews]

> In ruby for example you would have to write a bunch of validations per hand and a bunch of tests too, to check if those work.

In idiomatic Ruby it's more like one line in the struct definition vs one line in the model definition. ActiveModel and dry-validations have battle tested single line validations for this with automatically generated error messages.