Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

thume.ca

Post reply on HN
Print view View original

271–280 of 384 posts

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

#271

Post by gameswithgo »

galaxyLogic wrote: post #57

I think the big big result from this study is: "Python: half the size !". 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. 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. You…

was development time measured? loc count is not necessarily going to correlate well with time spent.

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

#272

Post by pkolaczk »

new4thaccount wrote: post #111
geofft wrote: post #79

Earlier quoted context omitted.

Tangentially - do you know how fast her compiler was compared to the compiled-language implementations? I have a vague sense that for many applications, interpreted languages are totally fine and reaching for a compiled language is premature optimization, but I'm curious how it actually holds up for a compiler, which is more computationally heavy than your average web app or CLI.

Yep, the takeaway for me was that the Python project required far less code, but we're not sure how fast it ran. Further below, the author states the inputs were so small it didn't matter. What if it did? Would the Python solution still be viable?

0.5x with metaprogramming vs 0.7x without in Scala, isn't "far less". This also matches my experience - Scala is pretty on par with Python in terms of code length. It gets a tiny hit from being statically typed, but then makes up for it by having richer stdlib and powerful type-level abstractions.

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

#273

Post by Kenji »

Avi-D-coder wrote: post #202

Haskell without lens, text, vector, etc... is a bit like rust with only core not std. The haskell standard library is tiny. Libraries like lens are not optional. In practice you won't understand any open source Haskell without rudimentary understanding of lens. I get why parser libraries were banned, but excluding lens, vector, and text? I like Rust a lot, but haskell minus it's more advanced type system is just Rust…

> I like Rust a lot, but haskell minus it's more advanced type system is just Rust plus GC.

Complete baloney. Haskell does not allow any imperative programming. Haskell is functional and disallows imperative, Rust supports functional but is largely imperative. Rust is vastly superior to Haskell and I say this as someone who has put many hours in both languages at this point.

Also, its*.

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

#274

Post by fmap »

foldr wrote: post #267
dymk wrote: post #244

Earlier quoted context omitted.

> However it is much easier to get what is a dictionary compared to a random "optic". This is exactly what I disagree with. We come from a prior understanding of mutable/imperative dictionary/shared_ptr/std::pair, because that's what we started out with. Had we been initially been trained on monads, functors, lenses, those would be the familiar tools, and we'd go "Huh, that's an... interesting way to write code" when…

Lenses don't really give you anything that you can't get from (a) a sensible syntax for record updates and (b) intrusive pointers. Lenses only exist because of Haskell 98's uniquely bad support for record types. Record access and update in most other languages just is simpler.

Lenses are more than reified record labels though. There is a hierarchy of concepts that can be freely composed based on which features your data structure actually supports. In particular, lenses can be composed with traversals ("lenses" pointing at multiple fields) yielding "LINQ" like features without introducing new syntax or concepts.

The main problem with lenses is that common lens libraries look extremely complicated at first glance and seem to be solving a very simple problem. That rightfully puts most people off of learning what all the fuss is about.

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

#275

Post by Avamander »

dymk wrote: post #236
StreamBright wrote: post #232

Earlier quoted context omitted.

Not at all. Several languages Rust included takes understandable errors seriously. I am a Rust newbie but the errors are extremely easy to grasp and fix my code.

You say "not at all", but only cite Rust (which I didn't mention). C++ has horiffic error messages, certainly at the level of a bad Haskell error message. I'd say my point stands pretty well.

Some C++ has horrific messages, new compilers do a much better job at complaining about most errors - some even suggest fixes. I don't remember seeing Haskell doing that.

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

#276

Post by oblio »

dymk wrote: post #236
StreamBright wrote: post #232

Earlier quoted context omitted.

Not at all. Several languages Rust included takes understandable errors seriously. I am a Rust newbie but the errors are extremely easy to grasp and fix my code.

You say "not at all", but only cite Rust (which I didn't mention). C++ has horiffic error messages, certainly at the level of a bad Haskell error message. I'd say my point stands pretty well.

So your defense for Haskell's error messages is that they're slightly better than what you get from a massively entrenched language with famously user hostile error messages?

Good luck with that :)

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

#277

Post by vphantom »

dean177 wrote: post #264
namelosw wrote: post #166

I'm surprised that OCaml takes 1.0-1.6x, given originally Rust compiler was prototyped in OCaml...

It mentions that this is almost entirely due to interface files on ocaml’s part. They unfortunately introduce a fair amount of duplication.

Luckily, they don't bring with them a lot of cognitive overhead for the developer, so their presence masks the expressiveness of OCaml in LOC stats IMHO. I use interface files to make public signatures explicit, abstract away some types and write thorough doc-comments. I'd be tempted to exclude them from such a comparison to better relate code size with programmer efficiency, especially when comparing to a language like Python.

On the other hand, in languages like C we couldn't exclude header files because they include macros. (Although I suppose a fancier comparison could count macros and exclude function signatures.)

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

#278

Post by mannykannot »

nybble41 wrote: post #147
mannykannot wrote: post #122

Earlier quoted context omitted.

> I think the big big result from this study is: "Python: half the size!". I would agree, if and only if I thought a representative sample of Python programmers would all produce something of a similar size and just as correct, but I suspect, in this case, it's the result of one especially talented person.

Raw talent and prior experience no doubt had something to do with it, but there's also the fact that the Python programmer was working alone and not particularly concerned about code quality or maintainability.

I agree (with the caveat that, as I wrote in another comment, I think being correct is an important aspect of quality), but this observation also argues against claims that attribute the outcome to the qualities of Python.

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

#279

Post by lngnmn1 »

Avi-D-coder wrote: post #202

Haskell without lens, text, vector, etc... is a bit like rust with only core not std. The haskell standard library is tiny. Libraries like lens are not optional. In practice you won't understand any open source Haskell without rudimentary understanding of lens. I get why parser libraries were banned, but excluding lens, vector, and text? I like Rust a lot, but haskell minus it's more advanced type system is just Rust…

GHC does not use lens and it is, it seems, ok.

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

#280

Post by p0nce »

objektif wrote: post #74
WalterBright wrote: post #50

Earlier quoted context omitted.

It's difficult to write a fair comparison without being a fairly competent programmer in each of the languages. The trouble is, if a person is an expert C programmer and then translates it to Python that he's only modestly familiar with, the Python program will look like C. It won't be idiomatic Python. For example, my early Fortran programs looked like Basic. My early C programs looked like Fortran. My early C++ pro…

How do you like D btw? Is it worth learning for a c++ programmer? I find the syntax very appealing.

> Is it worth learning for a c++ programmer?

I was a former C++ full-time programmer (4 different jobs in high performance teams, high maintenance etc) and now I'm a D full-time programmer for 4 years.

It's easy to underestimate the difference, but to me _as a user_ those languages are night and day as an experience.

D is learnable, in the sense that your learning will have some sort of ending at one point. D is surprisingly stable too, the front-end doesn't change too much and all 3 compiler share the front-end. And it's somehow forgiving. So the whole experience is tilted towards what you do with it: you feel like "programming", not "programming in C++".

C++ has a few things going for it: it has some sort of mathematical completeness, you can find jobs maintaining C++ codebases for your retirement, and it has an aura of legitimacy. But overall I fear you would live in a much more complicated world, for reduced productivity.

Post reply on HN