Comparing the Same Project in Rust, Haskell, C++, Python, Scala and OCaml

One big difference (which the article seems to mostly ignore) is that the shortest project was written by a single developer, while all others were a team effort.<p>Having the whole project - design, architecture, all implementation details - in one head is not a trivial advantage. Even ignoring communication overhead, there might be subtle duplication of code simply because different people choose to do similar things in slightly different ways.<p>While the ratio of Rust to Python code kind of matches my expectations, I wonder how much of it might be due to the difference in team structure vs the difference in chosen language.

Haskell without lens, text, vector, etc... is a bit like rust with only core not std.<p>The haskell standard library is tiny. Libraries like lens are not optional. In practice you won&#x27;t understand any open source Haskell without rudimentary understanding of lens. I get why parser libraries were banned, but excluding lens, vector, and text?<p>I like Rust a lot, but haskell minus it&#x27;s more advanced type system is just Rust plus GC. Lets not pretend this is a fair comparison of languages when it&#x27;s primarily a comparison of standard libraries.

Excellently written, great topic, and done w&#x2F;o flaming&#x2F;too much bias. I&#x27;m amazed as many older folks in the industry would not be able to have this level of content and maturity to write an informative article.

&gt; I think the smaller differences are also large enough to rule out extraordinary claims, like the ones I’ve read that say writing a compiler in Haskell takes less than half the code of C++ by virtue of the language<p>Specifically the &quot;by virtue of the language&quot; part:<p>Seems to me like it&#x27;s unreasonable to claim the languages are on equal footing because fancy parser libraries aren&#x27;t allowed to be used for the project. The fancy parser libraries exist for certain languages specifically because the languages enable them to be written. (For example in Haskell: monadic libaries, libraries that take advantage of GADTs, etc.)

I think the big big result from this study is: &quot;Python: half the size !&quot;.<p>A dynamic language like Python is better here, 2x better. I assume similar results would apply to other dynamic languages like JavaScript, Lisp, Smalltalk, Groovy etc.<p>This does not say that static typing should not be used but I think it shows unequivocally that there is a considerable extra development cost associated with static typing.<p>You might say that surely that additional cost would be compensated in reducing the cost of maintenance later. Maybe but I&#x27;m not sure.<p>Any development effort of significant size (like writing a compiler here) is a combination of writing new code and adapting and modifying code already written. &quot;Maintenance&quot; is part of development.<p>This is quite a quantitative study which gives credence to the claims of advocates of dynamic languages.

That was a really interesting article. I completely agree with<p>&gt;&gt;&gt; Abstractions may make things easier to extend in the future, or guard against certain types of errors, but they need to be considered against the fact that you may end up with 3 times the amount of code to understand and refactor, 3 times the amount of possible locations for bugs and less time left to spend on testing and further development.<p>Choosing when and how to abstract is key. Abstraction in a fashion extends the language so you are trading off a burden on the reader (who have to learn and trust the abstraction) for increased expressiveness. Don&#x27;t overdo it. (And don&#x27;t abstract idioms).

I really wish when counting code that people would use one of the more modern code counters, or at least use cloc. Tokei, loc, scc, polyglot, loccount or gocloc give a much better idea over wc because they account for comments and blank lines and in the case of scc and tokei strings.<p>I had a similar experience in university. Class had to implement a modified Turing machine. We could use whatever language we wanted. On person did it in C++ and it was several hundred lines. Another in Java which was slightly smaller. I implemented mine in Python and it was small enough to print on a single piece of paper. I think it was something like 30 lines or so. I exploited break statements to make it terse but readable. It did mean I was marked down a bit for them but it was by far the shortest program in the class.

Hey trishume! It’s been a while (this is the Reason person).<p>Great post; it echoes all the experiences I&#x2F;we’ve personally had, especially the alternative Rust section: on the spectrum of how much intelligence one needs to understand fancy abstractions, all of us programmers, good and bad, are pretty much lumped to the lower end. I’ve seen plenty of skilled folks “decompensate” their expertise by reaching for overly complex abstractions. The definition of a “strong” programmer, as per the post and usually in real world, should probably be rectified to include not only “the person knows how to use this abstraction”, but also “the person knows when to stop”.<p>In the same vein of idea, it’d be interesting to know how Go would fare in this project. Go’s philosophy is pretty much the opposite of a language that’s usually used for compiler research; but I’ve seen indicators that using it could be surprisingly effective (and in light of this post, maybe less surprising).<p>More importantly, it’d be nice to know the perf characteristics of each project =)

I haven&#x27;t made it through the whole thing yet, but I do want to register a vote in favor of using Lines Of Code count as a rough measure of program complexity. I think it&#x27;s a perfectly valid things to do, provided that it isn&#x27;t used as an evaluation metric and nobody is gaming it, and everyone is a reasonably good programmer, not doing crazy things like trying to stuff a massive algorithm onto one line to be clever, or copy-pasting the same code in 20 places because they don&#x27;t understand functions and classes.

My take-away from this article is that the university I graduated from was terrible

The Scala result confirms my bias :P I love Scala because it strikes a great balance between being succinct and offering type safety.<p>I wish you would use Ruby instead of Python. Python is strangely inconsistent. For example, Python doesn&#x27;t really offer a rich standard library; people have to resort to ugly solutions for a simple problem (here&#x27;s an example: <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;363944&#x2F;python-idiom-to-return-first-item-or-none" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;363944&#x2F;python-idiom-to-r...</a>)<p>Ruby would be better at an example of how a dynamic language can be more succinct.

If you&#x27;re into this sort of thing, definitely check out the ICFP Programming Contest -- take next Friday off and join in on the fun! <a href="https:&#x2F;&#x2F;icfpcontest2019.github.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;icfpcontest2019.github.io&#x2F;</a>

I&#x27;m sad that no one wrote it in the subset of Java that it was going to compile.

I conducted a similar exercise, albeit on a much smaller scale, when I was &quot;language shopping.&quot; I took a project that I had written in Visual Basic (my go-to language at the time), and re-wrote it in a variety of programming environments.<p>The project was just complex enough to require maybe 100-200 lines of code at the end of the day, thanks to liberal use of libraries. Not huge, but not atypical for a &quot;scientific&quot; programmer who uses code as a way to solve problems rather than to create software for others to use. It&#x27;s pretty representative of my life as a programmer.<p>The exercise forced me to learn enough of each language to get a feel for it, and then I could look at the programs alongside one another to assess their strengths. I also imposed some rules, such as that the language had to run on multiple platforms, and be FOSS. In addition to comparing the languages, I was also implicitly comparing libraries and even access to online help. This was also my first real exposure to StackOverflow.<p>I tested Javascript, Python, GNU Octave, and wxMaxima. Ultimately Python won out and is my language of choice today. This was just my own little exercise, and not worth publishing, but has made me a believer in learning multiple languages.

I like the idea of using this project to compare languages.<p>However, to me it seems the comparison is more of a comparison between specific implementations rather than languages. The high variance in LOC between the two rust implementations makes me wonder if there&#x27;s a similar variance for other languages and the samples we have lie somewhere between e.g. 0.5 and 2 times the average size for a given language.<p>Therefore, the python implementation could just be a really compact one, even when compared to other python implementations. It could be interesting to ask the Professor if he&#x27;d be willing to collect some stats over the years.

These comparisons are actively harmful. What the OP is doing is the same as if you were trying to determine the winner of a race by looking at the competitors at the start. You don&#x27;t know their speed, their strengths etc. You can&#x27;t determine how maintainable the code you produce this way, how it performs under real world usage, etc. Please stop doing these.

That is an important conclusion: &quot;design decisions make a much larger difference than the language&quot;.<p>Software developers&#x27; expertise varies more than expressiveness of programming languages.

I feel like what you&#x27;re actually testing with this is &quot;amongst the top percentile of programmers, what are the proclivities of people by choice of favourite language&quot;<p>Because the implementations vary so much, that&#x27;s the source of a lot of the LOC-difference. They effectively delivered more or less (if you count more stages as &quot;more&quot; which I would as it will make it easier to reason about&#x2F;debug, and count a typesystem as &quot;more&quot;, since it gives you more guarantees).<p>python - solves the problem brutally fast, some ugly shortcuts haskell - solves the problem quite slowly&#x2F;delivered the most rust&#x2F;c++ - intermediate scala - solved fast, took shortcuts ocaml - this is the one that surprised me I&#x27;d have expected it to be the shortest with python

I find it curious that both the team that used C++, and the author, both appear to believe that sum types and related facilities are not usable or conveniently expressible in C++.<p>I got that Boost Spirit, a powerful parsing library, was forbidden. Were all the Boost libraries similarly embargoed?

I think the right metric to measure here is not quantitative, but more qualitative.<p>In other words, how easy it is to adapt the language to the problem you are trying to solve.<p>So, in order to do that you need to have a good understanding of the principles each language is based on. Once you&#x27;ve got that, then you look at the resulting code and &quot;measure&quot; how easy it is to understand.<p>As was already said, this requires having someone with a very good understanding of the underpinnings of each language, which is not really going to be reasonable for most people.<p>The problem is that if you simply tried to port an idiomatic solution from e.g. C++ or Python into Haskell or Scala, or whatever, then you would probably end up with something very ugly, because you didn&#x27;t adapt the language to your problem. You tried to force it to do something it wasn&#x27;t necessarily designed to do.

Love reading your posts Tristan, a question about the choice of Rust. Was it specifically based on the previous experience you and your groupmates drew on or were these languages assigned to students? Was there any point in time where you and your team were trying to optimize your compiler?

Another big takeaway is the reusability of integration tests. Write once, verify implementations in any language.<p>Static or dynamic typing doesn&#x27;t matter that much if you can verify your software, and there are many different reasons to choose a particular programming language.

This is an interesting writeup, but I&#x27;d say the groups settling on different algorithms matters much more than the language used. It is obviously a pretty big difference whether you use a recursive descent or an LR parser.

It would be interesting to see experts in different technologies compete, in front of a live audience, to implement or change a variety of projects. It would be useful to see what a master can do with each tool or platform.

Is possible to see the code of this project? And is the same of <a href="http:&#x2F;&#x2F;thume.ca&#x2F;2019&#x2F;04&#x2F;18&#x2F;writing-a-compiler-in-rust&#x2F;" rel="nofollow">http:&#x2F;&#x2F;thume.ca&#x2F;2019&#x2F;04&#x2F;18&#x2F;writing-a-compiler-in-rust&#x2F;</a>?<p>P.D: I&#x27;m building a relational language and my ideas mimic closely &quot;writing-a-compiler-in-rust&quot; ie: using pratt parsers and similar, but not see much of how do that on rust...

Where&#x27;s the code? I scanned this article a few times and can&#x27;t find a link to it.

Ooo lolly! I want to do this in Prolog!<p>The bit about &quot;no parsing helpers even if they’re in the standard library&quot; makes me wonder about using DCGs, but if disallowed re-implementation would be straightforward and add only a small constant to the code volume.<p>I would like to see metrics on speed of compilation and size of resulting asm.

Great writeup, I&#x27;m very curious about the performance between the compilers.

I&#x27;ve condensed the relative source code sizes and notes for quick ref:<p><pre><code> Rust_1 1.0 using recursive descent, visitor Haskell 1.0-1.6x depending on how you count for interesting reasons C++ 1.4x for mundane reasons Python 0.5x fancy metaprogramming, dynamic typing, single author Rust_2 3x different design decisions Scala 0.7x LR table generator, online Java grammar OCaml 1.0-1.6x depending on how you count, similar to Haskell </code></pre> &gt; <i>AST visitors and recursive descent [...] weren’t taught in the course</i>

Interesting, but nothing to make any conclusions from. Too many variables to be of any use. Almost everything was different about these projects (different parsers, error handling, features, developer skill, team size).

Prolog, and Definite-Clause-Grammars <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Definite_clause_grammar" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Definite_clause_grammar</a>

The actual effort of writing one line of code in the specific language doesn’t mention in the article. Write one line of rust is extremely difficult than one line of Python, or even C++.

I&#x27;m not clear whether the SLOC counts are for the application itself or including their test harnesses. It would be good to have a table of results with this data.

First of all: amazing project. Kudos to your professor. Who is it, btw?<p>Second: intriguing how important meta programming becomes once you nailed the problem domain.

It&#x27;s too bad Clojure was not considered. I think it would be the most concise codebase and the most easiest to reason about.

I&#x27;m surprised that OCaml takes 1.0-1.6x, given originally Rust compiler was prototyped in OCaml...

How much time was given for this task?

and how much time does it take to <i></i>maintain this code<i></i>?

Is the code online somewhere?

No AWK and Ada this time? :)

Rust seems so ugly ... makes Perl line noise look like paradise. I guess it&#x27;s that time of the year ... when I have to learn an esoteric language to keep my sanity.

I wonder how Racket would compare. I’ve written some DSLs at an old job for Racket and found the libraries for language design almost unreasonably powerful (and maybe unreasonably complicated as well). The dynamic typing would also help in reducing the amount of code.

Loved this part and thought it was hysterical -<p>&gt; Since my team had all interned at Jane Street the other language we considered using was OCaml, we decided on Rust but I was curious about how OCaml might have turned out so I talked to someone else I knew had interned at Jane Street and they indeed did their compiler in OCaml with two other former Jane Street interns.<p>Relatedly this is why I get annoyed at people that don’t believe 10x or Nx developers exist - they absolutely do!

&quot;Their project was 17,211 raw lines, 15k source lines, and 637kb&quot;<p>So a couple of students cranked out 15K lines of code, in basically a subset of their study time, for a single class?<p>I don&#x27;t doubt they did it, what I doubt is the quality of what they wrote. Because it&#x27;s &#x27;just a project&#x27; it doesn&#x27;t have to be fully debugged ...<p>But that is a vast amount of code to hand-write over a short period of time.<p>At that level, I think it&#x27;s basically just &#x27;code like the wind&#x27; with not much consideration for whether it works, architecture etc. etc. - which in a way might put the conclusions of the &#x27;mini study&#x27; at odds.<p>At 15K LOC dashed out very quickly ... these are not products, they&#x27;re comparing &#x27;rapidly written out lines of code&#x27;, which is something else entirely from working code.<p>Also, given that everyone is in Uni, and likely may not have been exposed to proper idiomatic code for the language ... this presents another issue. Ideally we&#x27;d want to compare reasonably idiomatic code for one language, to another.<p>Kudos to the author for this, but we should be aware of some caveats.

I can hear all the Haskell fanboys screaming that they didn&#x27;t do Haskell right because a kleisli arrow didn&#x27;t appear and ascend them into monadic heaven.

Prohibition was an extremist political movement. Widespread public rejection of it, in the form of stills, speakeasy and other means proved it to be a law without public sopport, resulting in its repeal within 10 years - an absolute public rejection of a limit unsought by the majority. OP pov has zero basis in fact.