4 ms·

I think backend web development except for protocol and server is inherently a text processing work: 1. Parse http request map them to language data structures

• groovebits 7y ago
  I personally don't see it that way. Usually the bottleneck is the database.
  • dragonsh 7y ago
    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 7y ago
      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 7y ago
        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_ 7y ago
          Go is already being used in lots of microservices.
          • jashmatthews 7y ago
            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 7y ago
        > 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 7y ago
        > 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.
• kej 7y ago
  Most modern web frameworks will deliver requests to your application already parsed into whatever kind of data structure you want. Text processing is a very small part of backend development.