<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 18, 2020, 13:35 Luke Kenneth Casson Leighton <<a href="mailto:lkcl@lkcl.net">lkcl@lkcl.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>On Friday, December 18, 2020, Jacob Lifshay <<a href="mailto:programmerjake@gmail.com" target="_blank" rel="noreferrer">programmerjake@gmail.com</a>> wrote:<br>> The article compares/contrasts the http libraries from NodeJS,<br><br>yyeah that's about as helpful as comparing a plastic kid's bow and arrow to a Sherman Tank and saying, "but look, they're both weapons, no really!"<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Umm, Go (one of the languages used as a bad example of API design) is strongly typed last I checked...</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>however even there, the analogy is broken and flawed: making comparisons of strongly typed languages against polymorphic ones then effectively saying "strong typed languages are automatically better" entirely and completely misses the benefits of both.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">They do mention that languages such as JavaScript (& Python) are promoted based on the speed you can write an initial implementation, just that you require tons of tests and keeping different parts in sync and properly tested is a huge chore.</div><div dir="auto"><br></div><div dir="auto">The essay is taking the position that you may have an initial implementation faster, but all the testing and bug fixing will take more time than just having written it in a language like Rust with better API design in the first place.</div><div dir="auto"><br></div><div dir="auto">Rust, by contrast, encourages APIs such that most of the properties you'd need huge piles of tests for in traditional languages are automatically enforced by the compiler by using a good API design.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">polymorphic languages have the huge advantage of being able to satisfy the Liskov Substitution Principle *without* the need for the base class, older (prior-written) or newer code to even know that the new variant satisfying the LSP is even being used.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I would argue that that is often a disadvantage, because of the API interface being declared mostly in documentation which can easily be inconsistent, incomplete, out-of-date, or just plain missing. This forces libraries to avoid changing their implementation to avoid breaking code that was using part of what they thought was public API surface, but was intended to be private. A good example of why Rust's explicit compiler-visible typing, combined with good API design, allows for complete substitution of the implementation is Rust's standard library recently completely replacing their hashmap implementation with a totally different, much faster (often faster than even C++), implementation.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>where for strong declarative languages, due to the strict typing it is simply impossible to deploy LSP.... *unless the programmer has planned for that in advance* at the base level of the API.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Rust makes it very easy to deploy something like safe type-checked LSP, when desired, by using generics and traits (which are waay more powerful and flexible than base classes, and much harder to accidentally misuse than C++ templates). Quite a lot of rust code does that, btw. It also supports opt-in dynamic dispatch.</div><div dir="auto"><br></div><div dir="auto">Jacob</div></div>