4 ms·

I think it’s a bit extreme to characterise it as sanity vs insanity. I think you need at least one of a large stdlib or good dependency management. I love Go,

I think it’s a bit extreme to characterise it as sanity vs insanity. I think you need at least one of a large stdlib or good dependency management. I love Go, used it since the 1.0 release and have used it at work for years. No complaints about the language. But for the longest time Go didn’t have quality dependency management and pulling in dependencies was annoying. Building your programs with the large, high quality stdlib was the path of least resistance. Since Go 1.0 (2012) most new languages have coalesced on good dependency management. Rust, for example, copied Ruby’s bundler idioms since before 1.0 (2015). People who needed good quality libraries were able to pull them in with minimal hassle. That’s why they didn’t need a large standard library to succeed. I’ve written more about the tradeoff here - https://blog.nindalf.com/posts/rust-stdlib/ https://blog.nindalf.com/posts/rust-stdlib/ To you, I’d suggest using less charged language like sanity. In this case there’s a good technical case for both ways, and it’s not productive or nice to imply that people who choose a different path from you are insane.

bheadmaster 3y ago
> To you, I’d suggest using less charged language like sanity. To the grandparent, I'd suggest keeping the language as it is. Status quo in the current programming ecosystem is often insane, and when it is, we should call it out. > it’s not productive or nice to imply that people who choose a different path from you are insane. In a general sense, I agree. However, when it comes to programming, insanity is so widely accepted as normality that I think it would be counterproductive to blunt the language used to describe it. As an example of insanity for those who may (justifiably) think I'm talking out of my bottom - in NodeJS ecosystem the standard library is so bad that it is considered acceptable to use dependencies for even the simplest tasks, which caused the `leftpad` incident which broke countless programs.
- lifthrasiir 3y ago
  Leftpad is not appropriate here because Node.js didn't add any additional String methods anyway. Therefore it could have been prevented if JS proper had enough String methods beforehand, regardless of attitude towards dependencies. Grandparent's points in comparison are more about the scope of standard libraries. (And in terms of convenient String routines, Go is still a bit inferior to Python!)
  - bheadmaster 3y ago
    > Therefore it could have been prevented if JS proper had enough String methods beforehand, regardless of attitude towards dependencies. Grandparent's points in comparison are more about the scope of standard libraries. Leftpad could've just as well be a part of some standard library, like... > in terms of convenient String routines, Go is still a bit inferior to Python ... Go strings library :) https://pkg.go.dev/strings https://pkg.go.dev/strings
    - lifthrasiir 3y ago
      Maybe I should've been more clear about "scope". Standard libraries can pick their scope of functionalities and depth (or completeness) for each functionality. Nowadays every programming language is expected to come with a good string support, which is about the scope. But there are a lot of string operations you can support. PHP for example has `soundex` and `metaphone` functions for computing a phonetic comparison key. Should other languages support them as well? I don't think so, and that's about the depth or completeness because you can never support 100% of use cases with standard libraries alone. Ideally you want to cover (say) ~90% of use cases with a minimal number of routines. Leftpad was clearly due to the lack of depth in JavaScript and Node.js standard libraries. JavaScript now has `String.prototype.padStart`, and an apparent name difference suggests a good reason that some standard library may want to avoid it: internationalization is complex. A common use case is to make it aligned by padding space characters, but that obviously breaks for many non-Latin scripts [1]. And yet many people tried to use it, so `left-pad` was born with a suboptimal interface, and we know the rest. HTTP support is different. I totally agree that HTTP is something you want to support in a sorta native fashion, but a standard library is not the only way to do that. In fact it is not a good place to do that because it is generally slower to change (Go is a notable exception but only because its core team is very well funded and strongly minded). Python did support HTTP in its standard library for a long time, but it doesn't support HTTP/2 or HTTP/3 at all and Requests or urllib3 are now the de facto standard in Python HTTP handling. Modern languages try to balance this issue by having a non-standard but directly curated set of libraries. Rust `regex` is a good example, which may be surprising given than even C++ has a native regex support. But by not being a part of the standard library, `regex` was able to move much faster and leverage a vast array of other Rust libraries, and it is now one of the best `regex` libraries throughout all languages. That's what nindalf wanted to say by different "ways". [1] For example, `"한글".padStart(5)` will give you `" 한글"` but its visual width is larger than 5 "normal" characters. This is not merely a matter of fonts and Unicode has a dedicated database for the character width ("East Asian Width"). Some characters are still ambiguous even in this situation (e.g. ↑), and the correct answer with respect to internationalization would be: don't, use a markup language or (for terminals) a cursor movement instead.
begueradj 3y ago
It's funny that your comment here applauds Go but your blog post praises Rust.
- nindalf 3y ago
  It is possible for more than one language to be good. Both languages succeeded with their approach.
  - littlestymaar 3y ago
    “But how can you support two opposing sport teams, that doesn't make sense” Too many people on HN when discussing about programming languages unfortunately…
norman784 3y ago
I think there's a distinction between Rust and Go in that sense, Go has a clear objective, be a good (if not the best) language for writing web services (that's why Google developed it in the first place), that's why their stdlib is so rich to write this kind of applications, while Rust was developed to be the system language for the next 50 years, that's why the difference in stdlib. The only downside of Rust is that you have to pull more than 100 dependencies to build a simple hello world server (Tokio + Axum | Actix), then you need a database driver, most likely something that depends on SQLx (not sure here how many, dependencies), but one of my projects got near 500 transitive dependencies with only 20~ish direct dependencies.
- badrequest 3y ago
  Rust dependency management is the best parts of Go with the worst parts of NPM.
- WuxiFingerHold 3y ago
  You hit the nail with Go's initial purpose. That not only explains the high quality of the std lib in terms of http, but also the lower quality in other areas. By the way: You still need a DB driver with Go. They just provide an interface, which is cumbersome and error prone to use. That's why the community package sqlx exists. To create a hello world in Rust, one just needs to add two crates, which in terms pull many other crates. So yes, too many total deps for my taste, but an Axum server is much more feature full than a server build with Go's std lib.
- the_gipsy 3y ago
  Go's objective was "C but with GC and async runtime". It got adopted for web services by chance, a better alternative to nodejs or python in some aspects, but the zero-values end up being a huge footgun to serialization which is the bread and butter of web stuff.
trimethylpurine 3y ago
sanity - Soundness of judgment or reason. This doesn't sound extreme. The statement, "designed with sound judgement," doesn't carry the implications that you're defending from.

bheadmaster 3y ago

> To you, I’d suggest using less charged language like sanity. To the grandparent, I'd suggest keeping the language as it is. Status quo in the current programming ecosystem is often insane, and when it is, we should call it out. > it’s not productive or nice to imply that people who choose a different path from you are insane. In a general sense, I agree. However, when it comes to programming, insanity is so widely accepted as normality that I think it would be counterproductive to blunt the language used to describe it. As an example of insanity for those who may (justifiably) think I'm talking out of my bottom - in NodeJS ecosystem the standard library is so bad that it is considered acceptable to use dependencies for even the simplest tasks, which caused the `leftpad` incident which broke countless programs.

lifthrasiir 3y ago
Leftpad is not appropriate here because Node.js didn't add any additional String methods anyway. Therefore it could have been prevented if JS proper had enough String methods beforehand, regardless of attitude towards dependencies. Grandparent's points in comparison are more about the scope of standard libraries. (And in terms of convenient String routines, Go is still a bit inferior to Python!)
- bheadmaster 3y ago
  > Therefore it could have been prevented if JS proper had enough String methods beforehand, regardless of attitude towards dependencies. Grandparent's points in comparison are more about the scope of standard libraries. Leftpad could've just as well be a part of some standard library, like... > in terms of convenient String routines, Go is still a bit inferior to Python ... Go strings library :) https://pkg.go.dev/strings https://pkg.go.dev/strings
  - lifthrasiir 3y ago
    Maybe I should've been more clear about "scope". Standard libraries can pick their scope of functionalities and depth (or completeness) for each functionality. Nowadays every programming language is expected to come with a good string support, which is about the scope. But there are a lot of string operations you can support. PHP for example has `soundex` and `metaphone` functions for computing a phonetic comparison key. Should other languages support them as well? I don't think so, and that's about the depth or completeness because you can never support 100% of use cases with standard libraries alone. Ideally you want to cover (say) ~90% of use cases with a minimal number of routines. Leftpad was clearly due to the lack of depth in JavaScript and Node.js standard libraries. JavaScript now has `String.prototype.padStart`, and an apparent name difference suggests a good reason that some standard library may want to avoid it: internationalization is complex. A common use case is to make it aligned by padding space characters, but that obviously breaks for many non-Latin scripts [1]. And yet many people tried to use it, so `left-pad` was born with a suboptimal interface, and we know the rest. HTTP support is different. I totally agree that HTTP is something you want to support in a sorta native fashion, but a standard library is not the only way to do that. In fact it is not a good place to do that because it is generally slower to change (Go is a notable exception but only because its core team is very well funded and strongly minded). Python did support HTTP in its standard library for a long time, but it doesn't support HTTP/2 or HTTP/3 at all and Requests or urllib3 are now the de facto standard in Python HTTP handling. Modern languages try to balance this issue by having a non-standard but directly curated set of libraries. Rust `regex` is a good example, which may be surprising given than even C++ has a native regex support. But by not being a part of the standard library, `regex` was able to move much faster and leverage a vast array of other Rust libraries, and it is now one of the best `regex` libraries throughout all languages. That's what nindalf wanted to say by different "ways". [1] For example, `"한글".padStart(5)` will give you `" 한글"` but its visual width is larger than 5 "normal" characters. This is not merely a matter of fonts and Unicode has a dedicated database for the character width ("East Asian Width"). Some characters are still ambiguous even in this situation (e.g. ↑), and the correct answer with respect to internationalization would be: don't, use a markup language or (for terminals) a cursor movement instead.

begueradj 3y ago

It's funny that your comment here applauds Go but your blog post praises Rust.

nindalf 3y ago
It is possible for more than one language to be good. Both languages succeeded with their approach.
- littlestymaar 3y ago
  “But how can you support two opposing sport teams, that doesn't make sense” Too many people on HN when discussing about programming languages unfortunately…

norman784 3y ago

I think there's a distinction between Rust and Go in that sense, Go has a clear objective, be a good (if not the best) language for writing web services (that's why Google developed it in the first place), that's why their stdlib is so rich to write this kind of applications, while Rust was developed to be the system language for the next 50 years, that's why the difference in stdlib. The only downside of Rust is that you have to pull more than 100 dependencies to build a simple hello world server (Tokio + Axum | Actix), then you need a database driver, most likely something that depends on SQLx (not sure here how many, dependencies), but one of my projects got near 500 transitive dependencies with only 20~ish direct dependencies.

badrequest 3y ago
Rust dependency management is the best parts of Go with the worst parts of NPM.
WuxiFingerHold 3y ago
You hit the nail with Go's initial purpose. That not only explains the high quality of the std lib in terms of http, but also the lower quality in other areas. By the way: You still need a DB driver with Go. They just provide an interface, which is cumbersome and error prone to use. That's why the community package sqlx exists. To create a hello world in Rust, one just needs to add two crates, which in terms pull many other crates. So yes, too many total deps for my taste, but an Axum server is much more feature full than a server build with Go's std lib.
the_gipsy 3y ago
Go's objective was "C but with GC and async runtime". It got adopted for web services by chance, a better alternative to nodejs or python in some aspects, but the zero-values end up being a huge footgun to serialization which is the bread and butter of web stuff.

trimethylpurine 3y ago

sanity - Soundness of judgment or reason. This doesn't sound extreme. The statement, "designed with sound judgement," doesn't carry the implications that you're defending from.