81–90 of 218 posts
Earlier quoted context omitted.
Swift is useful if you're an Apple developer only targeting Apple users, seems like a bit of a niche.
Swift works reasonably well on Linux. You can even run Swift on Windows 10 through Windows Subsystem for Linux.
Something that I found about going from Haskell to Rust was that Rust provides many powerful abstractions without compromising on performance. It was very frustrating to try reasoning about performance in Haskell due to its laziness. Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in.
Wasn't the selling point of laziness performance? "It only does what is needed!" I didn't use Haskell but Nix and at least there it seemed reasonable to "not do" everything.
In Haskell when the compiler misses an optimization the performance hit is potentially unbounded, as it could think anything is a dependency. (You want the first N digits of pi? Just wait while I calculate all of them for you...)
Earlier quoted context omitted.
> .. you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C. Computer Language Benchmarks of GHC versus C don't seem to be close to matching your 80% as fast claim [1]. Also, the 10% of the effort of hand-optimized C bit - seem to recall there was a caveat - "if you happen to Don Stewart" [2]. The following is just my vague, uninfor…
The benchmarks game falls squarely under the umbrella of "short, simple programs", not the sort of real-world stuff where you would benefit from having a language that scales well. That said, Haskell performs pretty well in the toy benchmarks anyway. Your comparison between Haskell and Go is about market size, not language design. I suspect you would have a similarly hard time finding Rust devs as Haskell devs (i.e.…
Earlier quoted context omitted.
While "GHC is faster than CPython" is a fairly accurate generalization, I still think python performance is easier to reason about. Haskell can give you fast code, but sometimes it will be super slow for no obvious reason.
super slow for no obvious reason Obviousness is hard to pin down. What may be completely obscure to a Haskell beginner is obvious to a veteran. Is it really fair to count people's strict-language preconceptions against Haskell? I don't know. GHC provides a wealth of profiling tools that an expert Haskell user can employ to find space leaks. Heck, experts generally know where to look (excessive use of lists, spine-non…
Since performance is exactly a measure of the number of imperative steps that need to happen in a program, low level imperative langauages are going to win in performance-obviousness every time. (Rust probably beating C in terms of avoiding memory problems, C probably beating rust in terms of not supporting language constructs that can make a single line worse than O(1).)
"Accidentally" asking the language to do something time-expensive is as impossible in C as forgetting a free() in Haskell.
Earlier quoted context omitted.
> .. you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C. I don't mean to be personal, but your quantative claim smells a little like unsubstantiated BS. Do you have any data to back it up? > That said, Haskell performs pretty well in the toy benchmarks anyway. Currently, "pretty well" looks like GHC performance is 50% to 10% of…
The make errors are a bit weird because the programs build on my machine no problem. In parts haskells slowness seems to be because no one cares enough to work on it. Can't say for sure, though, so maybe I just should try a task and implement it to see how fast it'd be without amazing optimization foo. Although of course these benchmarks aren't really representative of the real world because they'd just end up as a c…
But then remember that @wyager is claiming
>80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C
If it's really only 10% of the effort then one shouldn't really have "to work on it" to get semi-decent performance.
A more modest claim of say:
50% as fast as hand-optimized C for only 20% of the effort of hand-optimized C
would have been more credible and still a big win for many use cases.
Something that I found about going from Haskell to Rust was that Rust provides many powerful abstractions without compromising on performance. It was very frustrating to try reasoning about performance in Haskell due to its laziness. Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in.
Haskell's laziness is an issue for you? Then how do strictness annotations (and/or module flags) not solve this problem? Haskell also has inline-C FFI support for "type safe" performance escape hatches (in the sense that you can manually bring C constructs into Haskell's type system): https://github.com/fpco/inline-c The only way that Haskell inescapably suffers from performance hits (that I'm aware of) is not in its…
Read about that technique from Simon Marlow of Facebook's Haskell team. Of course it would be awesome to not have to worry about that.
Something that I found about going from Haskell to Rust was that Rust provides many powerful abstractions without compromising on performance. It was very frustrating to try reasoning about performance in Haskell due to its laziness. Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in.
>Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in. +1 One approach that occurred to me was to use Haskell and Hackage for prototyping a design and then a Rust implementation for production. It also reminds me of this from several years ago: GHC honcho Simon-Peyton Jones saying the next Haskell will be strict, but sti…
SPJ made a great lecture about this. It is very easy to follow and a fun insight into the academic history of modern functional languages https://www.youtube.com/watch?v=re96UgMk6GQ
Earlier quoted context omitted.
I tried implementing some simple imperative algorithms (like union-find) and found the Haskell code very noisy. For example, "var x = f(y)" in an imperative language might translate to "let x = f y" or "do x <- f y" in a Haskell do block, and the wrong variant won't compile. There's no general purpose idiom you can use to replace all loops, only tons of special purpose HOFs you must memorize. Writing code that mixes…
Just because it doesn't translate 1-to-1 from another imperative language doesn't mean it isn't imperative itself. Haskell is not in the C family. It's not going to accept straight translations from C, but C doesn't monopolize imperativeness either.
Earlier quoted context omitted.
Yeah right. If only the standard library (the base package) could immediately be converted to use linear types and we can all benefit from that! (Hint: it won't. Even the fairly no-brainer AMP and BBP took an absurdly long time. This is extremely slow by Rust standards. The Haskell community might, but the stewards of the standard libraries don't have the move-fast-and-break-things attitude.)
Did rust ever have a large scale breaking change? Anyway, the linear type proposal is designed to be completely backwards compatible so that shouldn't be as big of an issue.
Pre 1.0: every day
Post 1.0: not really, though I guess it depends on your definition of "large scale"; we've made some soundness fixes, but made sure that they were warnings for a long time first, so most people experienced no breakage.
Earlier quoted context omitted.
Although clearly presented to push some buttons, it isn't completely wrong. Am upvote hoping you don't get buried.
it isn't completely wrong It may get some of the facts right, but the tone is completely wrong. Cynicism is just a step or two away from nihilism. It's far, far easier to destroy than it is to create. The world needs more creators, not destroyers.
Totally off topic:
Such a simple thing to say, but I thank you for it. I often want to do good, and spent time thinking about the problems in the world and how my path might help them, but I know that I am a massive cynic in many areas. Politics being a big one.
I have always agreed with your statement about creators vs destroyers, but nevertheless I've been a loud cynic. I need to reign that in. Thank you.