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

251–260 of 384 posts

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

#251

Post by dymk »

nybble41 wrote: post #141
aetherspawn wrote: post #80

Earlier quoted context omitted.

To be fair, I don’t think any Haskeller would actually write this project without attoparsec and maybe lens by choice. They’re basically base libraries for this sort of thing.

Agreed. The rule about not using any library that doesn't ship with the compiler creates a heavy bias in favor of "batteries included" languages like Python. I understand not allowing parsing libraries, given the nature of the assignment, but if even widely used libraries like lens are off-limits the result is not going to resemble idiomatic Haskell. As a matter of basic fairness, if some library or built-in language…

I think a much more interesting comparison would be to ask an expert in each one of these languages to implement a "production" ready version of the project - so allowing popular, stable, community-accepted libraries to be used.

Then we'd see what truly idiomatic solutions to this look like.

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

#252

Post by gmueckl »

blumomo wrote: post #187
pm90 wrote: post #148

Earlier quoted context omitted.

But the Python code was also smaller. Easier to learn and maintain.

"Smaller code" does not mean easier to understand. It just means less characters to read. Maybe those characters are heavily loaded with meaning, as in the case with meta programing. You might need twice as much time to _understand_ the Python Code vs. the Rust code. The Rust code might be easier to extend, etc. So this is all comes to trade-offs at the end. All this being said, I'm still a huge Python enthusiast.

Smaller code may also mean more entangled and more rigid design. But that is hard to tell from just the line count.

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

#253

Post by [deleted] »

k_bx wrote: post #245
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 disagree about lens. My new projects don't use them in main code-base and it was a great decision: - TAGS work like a charm to access field definitions - compile times are ok Of course, if library's API needs lens, they're used.

[deleted]

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

#254

Post by runeks »

orbifold wrote: post #235
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…

That's a total stretch, lens is not used in GHC for example and lots of other smaller compilers written in Haskell. It is used in Ermine but that is stuck in a semi complete state for a while now and Ekmett has moved on.

I second this.

I’ve written tens of thousands of lines of Haskell, and I’ve never used lens. Also, putting it in the same category as text and vector doesn’t make sense — these are indeed unavoidable, and practically all my projects use them.

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

#255

Post by pjmlp »

StreamBright wrote: post #233
tigershark wrote: post #160

Earlier quoted context omitted.

There were people with 2k to 10k loc of experience in some language. That seems extremely low for any meaningful comparison and I would really hope that “average” programmers have way more experience than that... I think I was pretty junior after writing north of 100k loc and working on 1M loc projects. And for sure I don’t consider myself highly competent in F# after writing some thousands lines. I agree with the co…

Sure but 100k LOC Java is bot equal to 100k LOC Rust or Clojure because there is a huge discrepancy between expressiveness of those languages.

It also depends if one is using Java 12 or Java 1.4 programming style.

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

#256

Post by runeks »

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…

> I think the big big result from this study is: "Python: half the size !".

> 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.

Are you saying that the bottleneck in software development is typing in text on a keyboard?

If so, I thoroughly disagree. In my experience, inputting text is a small factor in development cost, with the main cost being research (figuring out what to type in), and debugging (figuring out why something you typed in doesn’t work as you thought it would).

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

#257

Post by lapw »

bfung wrote: post #37

Excellently written, great topic, and done w/o flaming/too much bias. I'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.

The older folks wouldn't compare toy compilers in this pseudo-serious manner.

I find it annoying that any trivial topic is dealt with in a self-important, "mature" manner.

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

#258

Post by grumdan »

fnord123 wrote: post #249
grumdan wrote: post #242

Earlier quoted context omitted.

Describing two well-engineered compilers of two relatively used languages as not impactful is quite a statement. In particular, given the good performance results they achieve, for languages that are quite far away from the normal execution model of the machine they produce code for.

>two relatively used languages Relative to what? Haskell and OCaml are important languages for PLT but not in the context of "production", or as I understood "production" to mean: shipping products with features. To call them anything but niche players in this context is not accurate in my opinion.

As in, there are a handful of large projects the languages are used for. For Haskell, Facebook's spam detection system, Sigma[1], comes to mind, along with some use by banks (Standard Chartered); then there's a bunch of smaller places using Haskell (Wire, a secure messaging app, like Signal; Galois, a US defense contractor doing software verification and related things) plus some open-source tools like pandoc.

I know less about OCaml, but at least Jane Street is using it.

It's somewhat niche, but it's not like it's only used for hobby or toy applications.

[1] https://code.fb.com/security/fighting-spam-with-haskell/

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

#260

Post by jcora »

fnord123 wrote: post #249
grumdan wrote: post #242

Earlier quoted context omitted.

Describing two well-engineered compilers of two relatively used languages as not impactful is quite a statement. In particular, given the good performance results they achieve, for languages that are quite far away from the normal execution model of the machine they produce code for.

>two relatively used languages Relative to what? Haskell and OCaml are important languages for PLT but not in the context of "production", or as I understood "production" to mean: shipping products with features. To call them anything but niche players in this context is not accurate in my opinion.

I don't think language use industry-wide is a good metric for how relevant compiler software is. It is entirely imaginable that a very serious compiler that proves the original point exist for a language with very rare industry use.
Post reply on HN