Live data from Hacker News

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

thume.ca

371–380 of 384 posts

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

#371

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.

[deleted]

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

#372
post #254

Earlier quoted context omitted.

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.

Thirded. No lens in pandoc (50k lines of haskell), darcs (40k), most hledger packages (15k).

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

#373

Earlier quoted context omitted.

There are not too many dynamically typed languages that truly allow you not to miss static typing. One of them is Clojure. I can't explain exactly how, but somehow I think Clojure is fine without them. I don't think I can say the same thing about JS, Lua, Python or Ruby.

I spent a couple of years working in a Clojure shop with people who actually like Clojure, and the experience for me was not so practically different than if everything had been written in Ruby (and indeed, half the codebase was a legacy RoR system). You either have a type-checker and compiler, or you don't.

Was it before Spec? In my experience - wise use of Clojure.Spec makes a big difference.

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

#374
post #283

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

> Having the whole project - design, architecture, all implementation details - in one head is not a trivial advantage.

It's also a big disadvantage if that one person ever wants to move on. I write this from personal experience; don't be a solo developer on a large project if you can help it.

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

#375
post #4

I'm sad that no one wrote it in the subset of Java that it was going to compile.

It's more surprising because javac is itself written in Java. It's definitely up to the task (even if it's targeting x86 instead).

Maybe no one thought of the immense satisfaction they would get at the end when they compile their compiler to x86 code after compiling it with javac to bytecode to run it the first time.

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

#376
post #363

Earlier quoted context omitted.

As I have aged, I have learned that duplication of code can become a feature in terms of building redundancy inside of teams. This is one of the reason that "enterprise code" really sucks, but the people turn-over and need to transfer knowledge over generations is more important than minimalism and the power of individuals (sadly).

> […] I have learned that duplication of code can become a feature in terms of building redundancy inside of teams. Could you elaborate on how this works?

It runs to the idea that perfection is the enemy of good, and how do you change perfection?

In a growth company with massive scale, a system always has some risky red-line, and so it is better to spin up some competing efforts with different perspectives to tackle different needs in different ways.

The key is to have redundancy of people over time and to create multiple thought leaders within a company; this makes it interesting. Then, at a future date, a "re-org" will happen to condense efforts and the real product is having a number of people familiar with the ideas spread across the company.

This makes zero sense for start-ups, but when you are a risk taking company with massive budgets... strategies are interesting. You see this with VCs having stakes in similar investments as well, and the idea is the same... diversify over people rather than perfect minimal code.

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

#377

Earlier quoted context omitted.

I spent a couple of years working in a Clojure shop with people who actually like Clojure, and the experience for me was not so practically different than if everything had been written in Ruby (and indeed, half the codebase was a legacy RoR system). You either have a type-checker and compiler, or you don't.

Was it before Spec? In my experience - wise use of Clojure.Spec makes a big difference.

They used Spec. Indeed wise use of a tool like this does make a difference, but then the onus is on the developer to be disciplined enough to apply it appropriately. Humans do not by default have this discipline.

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

#378

Earlier quoted context omitted.

Same for me, except also the incredibly obtuse set of ~20 compiler pragmas you need in Haskell. If you ask for help to do some simple programming concept, like multiple dispatch based on type at runtime, then from the Haskell community you first get a bunch of tone deaf “you shouldn’t want to ever do that” responses, followed by a huge tome of all the language extensions (fundamentally changing or adding syntax) that…

With the exception of very few extensions that I've never seen used in practice, Haskell language extensions are mutually compatible and create a language that is a strict superset of the old language. In this sense, I'm not sure how they're much different than the --c++=14 flag in GCC.

If you need to know and understand syntax implications on highly generic type pattern constructs coming from a dozen external pragmas, just to be able to read the code then it’s a severe language design problem.

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

#379

Earlier quoted context omitted.

There was a general prohibition on libraries that don't ship with the compiler, but you could ask the professor for an exception. Someone asked about Boost and a blanket exception for the non-parsing and scanning parts of Boost was granted. However the C++ team I talked to didn't use it. Also note that it's not only the sum types that are important, powerful pattern matching facilities are part of what makes them so…

C++ has had sum types for years, so I'm not sure why that was mentioned. If you aren't familiar/experienced with the language, then the comparison is not fair overall.

It is correct to note that C++ lacks some core language features that many newer languages have, tailored to more convenient and, often, safer use of slippery sum types. Sum types are a step away from lexical typing, and without that support add risk that strong typing was invented to contain.

There is an active project to have a powerful pattern-matching primitive ready in time to adopt into C++23. In the meantime, C++17 supports "structured bindings" that are often helpful.

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

#380
post #230

Earlier quoted context omitted.

> D won't get you hired (probably) On the contrary. Many members of the D community have managed to leverage their D expertise into well-paying jobs. Many industrial D users recruit from the D community.

Not me though! I was aware of that but I meant in comparison to (say) Java or JavaScript etc.

https://www.digitalmars.com/d/archives/digitalmars/D/announc...
Post reply on HN