<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 25, 2016 at 3:21 AM, Jerry Leichter <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[Description of cool features in Rust.  I'm really going to have to go look at it now]<br>
<span class="">> What other languages are suitable for "I need every drop of performance and control", yet are this safe? Serious question. A question we should be asking.<br>
</span>Many of the ideas in Rust that you describe seem to have evolved (or were independently reinvented - I have no idea) from Modula-3.  Small, fast, extensively type-checked, ability to explicitly write unsafe code.  All there.<br>
<br>
The Modula-3 guys had an interesting approach to keeping the language small:  </blockquote><div><br></div><div>I recall a conversation between N.W. and another about Modula-2 and the lack of a standard </div><div>library for I/O.    Niklaus Wirth was adamant that a standard lib was not part of the language.<br><br>Lacking a standard lib set was both good and bad.  I happen to like his point but<br></div><div>it hurt the adoption of a good language.</div><div><br></div><div>On the good side well designed libraries can replace the initial "get-er-done" libraries.</div><div>Improved functionality could be coded and could replace previous libraries. <br>Both ABI and API issues... apply.  <br>If standard I/O and the like are baked into the standard the <br><br>Most if not all  languages do not have "deprecation" as a primary feature</div><div>of the language and system.   A current compiler system should be able to </div><div>deprecate libraries and versions  of libraries.</div><div><br>Shared libraries put the same bug in lots of applications all at the same time</div><div>and can remove a bug from many applications...<br><br>Google Go had potential and still does but many programmers what access to</div><div>libraries of features that they already know.   It is hard to construct a wrapper </div><div>that makes ill designed old libs safe.<br><br>Performance... inside an application programmers try to run fast by removing </div><div>bounds checks and "assert(all-data-is-good-here)".  Most have no quality idea</div><div>how to check that the assertion is true and test it in a correct and safe way.<br>The difficulty in making a quality assert() is evident in the way to common bogus </div><div>assert related bugs i.e. these are often hard.</div><div><br></div><div>Programmers and mechanical engineers have much the same problem... <br>Example: A high speed cutter exposed and unprotected is dangerous.  Correctly</div><div>used and surrounded with guards and interlocks inside a machine all is good</div><div>as long as the feeds and exits are safe.<br><br></div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div>
</div></div>