<div><br></div><div>Hello Magnus,</div><div><br></div><div>On Mon, Jan 24, 2011 at 10:06 AM, Magnus Rattfeldt <span dir="ltr"><<a href="mailto:magnus@rattfeldt.se" target="_blank">magnus@rattfeldt.se</a>></span> wrote:</div>
<div><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
I am considering choosing SML and MLton for a new side project where I<br>will build a framework for local search optimisation algorithms. I<br>have previously written such a framework in OCaml during my PhD<br>studies. Now that I am going to more or less reimplement everything,<br>
it is a good opportunity for me to try out MLton and its whole-program<br>optimisation philosophy.</blockquote></div><br>I am glad you are considering MLton. I am not a developer, but I am a very satisfied <div>user of MLton. Your questions are certainly reasonable, so let me share some </div>
<div>thoughts that might help mitigate your concerns.</div><div><br></div><div>I work for a small company (9 people) that develops testing and validation tools</div><div>for embedded applications. Most of our customers are in the automotive and </div>
<div>aerospace industries. Our main product is implemented in SML and we currently</div>
<div>use MLton. We have used SML here since the start of the company in 1999 and</div><div>MLton for the past several years. We currently have a code base of several hundred</div><div>thousand lines of SML code. </div>
<div><br></div><div>There are a number of other companies who use MLton in successful commercial </div><div>products as well as dozens of very large applications developed at universities </div><div>and research labs. Some of these are listed here:</div>
<div><br></div><div><a href="http://mlton.org/Users" target="_blank">http://mlton.org/Users</a></div><div><br></div><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, when I look at the (latest) MLton release cycles and the<br>
mailing lists it seems to me that the MLton development is not very<br>
active anymore (3 years between the two latest releases, rather low<br>
svn activity, not a very active user/developer list). So I am a bit<br>
concerned of choosing MLton due to this. </blockquote><div><br></div><div>While these could be taken as indicators of a declining project, I believe they are more </div><div>due to the fact that MLton is a mature tool that is extremely stable. In our experience </div>
<div>with a large code base originally developed under a different compiler, we have found</div><div>only a handful of issues in MLton all of which have now been addressed. </div>
<div><br></div><div>In addition to being robust, we have also found MLton to produce extremely efficient executables, both in terms of speed an memory usage. </div><div><br></div><div>So since MLton works well there is not a huge need for super frequent releases. In </div>
<div>a perfect world, less than 3 years might be nice; but, in my mind fewer releases that </div><div>are rock solid are preferable. </div><div><br></div><div>As for traffic on the mailing lists, admittedly, it is not huge. But as I look back over the </div>
<div>past couple of years, there is at least some traffic every month. Pretty much any issue</div><div>raised gets a quick response. Some responses are quite in depth discussions of </div><div>complicated topics. </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As performance will be essential for my application, falling back on </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
another (of the current ones) SML implementation in the future is not appealing.<br></blockquote><div><br></div><div>While I think it highly unlikely that there would be an obstacle blocking your use</div><div>of MLton, having other world class compilers to "fall back" on is not a bad option </div>
<div>to have. One nice benefit this gives you is an easy way to test the compiler. </div><div>We compile our application with both MLton and SML/NJ and compare the </div><div>results against each other. </div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I would like to ask here if my concerns are justified? Or can I<br>
choose MLton and be confident that its development will continue,<br>
possible bugs be fixed, and perhaps even that new features and<br>
optimisations will be implemented?<br></blockquote><div><br></div><div>Having used OCaml, you already know the benefits of the ML family. I think</div><div>you will not be disappointed if you give MLton a try. It has certainly exceeded</div>
<div>our expectations.</div><div><br></div><div>Best Regards,</div><div>Steve</div><div> </div></div>-- <br>Steve Sims<br>Chief Executive Officer - Reactive Systems, Inc.<br>Email: <a href="mailto:sims@reactive-systems.com" target="_blank">sims@reactive-systems.com</a><br>
Phone: (+1) 919-324-3507 ext 101 <br>
Web: <a href="http://www.reactive-systems.com/" target="_blank">http://www.reactive-systems.com/</a><br><br><br>
</div></div>