4 ms·
Haskell is only close to C in extremely rare cases or when using unsafe features and the FFI.
by nonsense1234 6y ago
Haskell is only close to C in extremely rare cases or when using unsafe features and the FFI.
- the_af 6y agoWould you say idiomatic Haskell is faster or slower than idiomatic use of Java and the JVM? I'm interested in actual experience and preferably benchmarks of real cases, no thought experiments please :) (If this sounds harsh, it's not my intention. In another HN thread I had someone "explain" to me how Java and Java's OOP is "not suitable for business software development". If this seems like a bizarre statement which disregards more than a decade of business software development -- this is why I ask for actual experience and not opinions or "I think this can't be right").
- wtetzner 6y ago“Unsuitable” doesn’t mean it can’t be done. Having written a lot of business software in Java, I actually agree it’s unsuitable. The only way I’ve been able to make it bearable is by using Lombok and pcollections.
- the_af 6y ago> I actually agree it’s unsuitable How so? Performance? Reliability? Verbosity? Which language is suitable in your opinion? To me this kind of opinion-based... um, opinions... fly in the face of evidence. Java has been used for more than a decade to deploy business software to great success. What more evidence does one need? It'd be like arguing "COBOL is unsuitable for banking". In the meantime, opinions have shifted on best engineering practices, and Java has naturally run the gamut of all these opinions. And because there are tons of Java systems, there's no shortage of examples of failed/bad projects one could pick on. I wonder how many languages/platforms would have fared better...
- wtetzner 6y ago"Unsuitable" meaning it's not a great choice. Yes, it's been done a lot (whether or not you can really say "to great success" is another matter, I think). What I mean is that I think using Java meant the company was required to spend more resources than should have been necessary to accomplish their goal. BTW, when I say "Java", I mean the language, not the platform. Java-the-platform is very suitable to business software. Java-the-language, less so. Java OOP brings with it a ridiculous amount of incidental complexity, boilerplate, and impedance mismatches. Of course you can make it work, I do it every day. I just think it's a poor choice. It's certainly not the worst choice, and the platform + available libraries is definitely a plus. And as I mentioned in my original post, there are way to make it more suitable through various hacks (like Lombok) and libraries, but other languages are more suitable out of the box (including other JVM languages).
- mrkeen 6y agoIf you liked pcollections, you might also like https://www.vavr.io/ https://www.vavr.io/
- mrkeen 6y agoThese benchmarks seem pretty good. Filterable by language, etc. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ The source code is published too (https://github.com/TechEmpower/FrameworkBenchmarks https://github.com/TechEmpower/FrameworkBenchmarks)
- bcrosby95 6y agoLots of people hate Java. It's unsuitable for those people. There are certain things you might have trouble getting Java to perform, such as strict latency requirements. Another language might be more suitable for that. But that generally doesn't describe business software. Desktop software is somewhere you probably don't want to use Java. Although if it's business desktop software, it might be a good fit since it can be cross platform (but ugly - but if it's business, it might not matter). We've built several desktop apps for warehouse computers in Java. Getting the JVM on a machine may or may not be a hurdle. This is one of many reasons why Go is getting popular - you can just build a binary. The positive of Java is that if you want to do something in it, someone else has probably tried. It has several large organizations backing professional quality libraries and frameworks that have had a ton of resources poured into them. It's easy to build on the shoulders of giants while relying on 3rd party libraries that don't have a bus factor of 1 - this is rare in many other languages. If you want stability and well trodden paths, it's hard to go wrong with Java. We've had projects that continued to just work from Java 1.4 to Java 8 - a span of almost 15 years without ever having to touch the code. Java 9 was a bit of a hurdle because of project Jigsaw.
- the_af 6y ago> Lots of people hate Java. It's unsuitable for those people. Understood, but I'm specifically excluding those opinions because they tell me nothing and are unrelated to suitability. Some Smalltalk folk will tell you nothing that is not Smalltalk is suitable for anything; how much would you value their opinion when determining whether a language is suitable for development? "I hate $LANGUAGE, therefore it's unsuitable for $DOMAIN" is the lowest, less useful form of opinion. It belongs in the realm of flamewars, not of informed decisions. Suitability to me is not related to whether I hate or like a language. I hate COBOL. I've worked with it. I'd never in a million years argue it's not suitable for banking systems, because that would run contrary to established history. As for other applications: I agree Java is not suitable for everything. I specifically argued about business software. That said, what about Minecraft, a hugely successful desktop game? :)
- alexhutcheson 6y ago> Getting the JVM on a machine may or may not be a hurdle. jlink[1] makes it pretty easy if you're using a recent JDK. [1] https://docs.oracle.com/javase/9/tools/jlink.htm https://docs.oracle.com/javase/9/tools/jlink.htm
- igouy 6y agoWhich person's idea of idiomatic ? "One can, with sufficient effort, essentially write C code in Haskell using various unsafe primitives. We would argue that this is not true to the spirit and goals of Haskell, and we have attempted in this paper to remain within the space of reasonably idiomatic Haskell. However, we have made abundant use of strictness annotations, explicit strictness, and unboxed vectors. We have, more controversially perhaps, used unsafe array subscripting in places. Are our choices reasonable?" http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf http://www.leafpetersen.com/leaf/publications/ifl2013/haskel... Programs for the n-body and spectral-norm procedural benchmarks game tasks, perform kind-of the same in Haskell and Java https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/haskell.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...