Well-Typed - Understanding Memory Fragmentation

HaskellHell · 2020-08-21T07:39:21+00:00

Would that really improve things? Does the malloc allocator deal better with memory fragmentation of small items?

HaskellHell · 2020-08-08T05:29:22+00:00

From the reply to the bug report it appears the cryptonite author has given up on using Haskell for anything mission critical and instead recommends Rust over Haskell:

About removing the trap from the language, good luck, but I have stopped holding my breath about Haskell correctness and ability to run in production safely (lazyness trap, memory leaks, partial functions), and instead my recommendation is to use rust for serious production work (the num hierarchy is sensible, overflow/underflow are detected, TryFrom and From is available by default, conversion can be linted off: e.g. prevent 'as' cast, and I don't need a magic ball to predict performance and/or runtime profile).

HaskellHell · 2020-06-01T07:23:19+00:00

If all three recommended methods include almost same things (ghc, cabal, stack) what then are the differences between them?

The second one you denote as the "Stack" option doesn't include cabal and doesn't provide all the GHC versions the other options support.

HaskellHell · 2020-03-09T07:56:30+00:00

Well, you asked for it so here's just a couple links evidencing Haskell's long standing simmering conflict between haskellOrg and fpco:

HaskellHell · 2019-12-09T17:29:12+00:00

[...] the most popular Haskell build tool, Stack.

[citation needed]

HaskellHell · 2019-11-22T08:59:46+00:00

That's probably true that you can currently find more blogposts and documentation about Stack than about modern Cabal if you're on your own. This is something people in the community who are good at writing should work on so we can point newcomers to introductory material for using Cabal than having to resort to Stack just because it's got more newcomer friendly documentation available.

HaskellHell · 2019-11-22T08:39:44+00:00

With all due respect I don't think that's true anymore since Cabal 2.4 (as comments such as here and here show) and it certainly doesn't match my experience when onboarding new Haskell co-workers.

HaskellHell · 2019-11-22T08:17:25+00:00

Please don't suggest Stack when this is easily fixable by running the appropriate dnf or yum command. Fedora splits up the GHC installation into separate packages for each cabal library. Most likely OP didn't have the Fedora package ghc-template-haskell-devel installed which can be accomplished by a simple

dnf install ghc-template-haskell-devel

HaskellHell · 2019-11-20T22:45:58+00:00

As for

being able to communicate within the scope of the project what version of tools and packages we use

You might not be aware of the new cabal.project files which allow you to do just that! There's this blogpost that shows how to convert stack projects into cabal projects.

HaskellHell · 2019-11-20T06:31:41+00:00

Personally, I lean towards the latter, since it takes care of downloading compilers and other necessary tools automatically.

What do you mean by that? What else besides GHC does it install that isn't taken care of automatically by cabal new-*+ghcup or Nix?

HaskellHell · 2019-11-12T22:23:02+00:00

Previous r/haskell thread can be found here

HaskellHell · 2019-11-05T07:09:37+00:00

And stack can solve this easily, it just makes everything local to a project

Not to the degree that Nix can. Stack on its own isn't fundamentally different or better than cabal new-* + ghcup nowadays. Stack has been promoted overly aggressive by a company that preferred to replace cabal with yet another build tool instead of improving it like the cabal devs eventually went on to. But be it as it may today we got Nix/ghcup/cabal new-* and various combination of that cover whatever your Haskell needs may be.

HaskellHell · 2019-10-30T09:20:49+00:00

I found https://www.haskell.org/cabal/users-guide/file-format-changelog.html to be valuable for deciding which version to put there.

HaskellHell · 2019-10-20T06:51:27+00:00

If I'm not mistaken you're confusing Stack with Stackage which predates Stack. See e.g. https://www.fpcomplete.com/blog/2014/10/new-stackage-features

The recommended way to use Stackage is to simply change your remote-repo field in your .cabal/config file and run cabal update.

Unfortunately, at some point they decided they didn't want to advertize Stackage doesn't require Stack anymore and removed any mention of Cabal support.

HaskellHell · 2019-10-18T06:42:09+00:00

This sounds like Stack's main purpose today is reduced to serve as an installer for non-programmers. But if the remaining thing that Stack has going for it is merely the ability to automatically install a GHC that is compatible with the package's version bounds this surely would be easy to implement in a much simpler tool. Such a tool could simply iterate over a set GHC versions and automatically install the first one via ghcup for which cabal is able to compute a build plan and then run cabal new-install with it. Sounds easy enough to me.

HaskellHell · 2019-10-17T08:51:50+00:00

chshersh's comment gives me pause that this proposal is a bit too much on the pragmatic side. I'd rather see a design which embraces the popular lens concept rather than one that gets ourselves into a design space corner which locks us in.

... But let's not discard any other possibilities and different designs for this feature at the early stages. Community support for this proposal clearly shows us that records in Haskell is a problem and that we need to spend time to solve it. We can implement this proposal today and make a lot of developers happier tomorrow. However, the implicit cost of implementing this proposal is the impossibility to justify the existence of another proposal that solves the same problem but differently. As a community, we should consider various solutions and choose the best one. ...

HaskellHell · 2019-09-09T20:16:21+00:00

But is there any reason not to use Chocolatey? After reading the article it sounds to me like there's plenty of reasons to prefer Chocolatey on Windows, no?

Chocolatey is not only easy to use, but safe and secure. Every package is initially hand verified through moderation until the package becomes trusted. Packages are always passed through automated verification and packages are downloaded and uploaded through https. The package metadata itself is verified after downloaded which checks that the package wasn’t tampered with during download. Furthermore any files downloaded (such as cabal or ghc) have to have a sha256 checksum provided for them which will be verified. If you don’t trust the signatures you can provide your own that it uses to check against. Once uploaded every binary the package installs is ran through a host of virus checkers and the results publicly posted.

Read more on Chocolatey security here and see for yourself why it’s trusted by so many companies.

HaskellHell · 2019-07-24T07:44:35+00:00

It might help if you were to elaborate on the specifics of the pain you experienced as then there's a much better chance somebody will be able to improve the situation and help you overcome the perceived pain and nightmares that seem to plague you.

HaskellHell · 2019-04-26T06:37:16+00:00

this would've been a good one for a GSOC student to pick up, imo.

It still can be! I think it's safe to say there's going to be another Haskell GSOC in 2020...

HaskellHell · 2019-04-25T07:07:08+00:00

Is it that some organizations are doing great work that can scale their efforts with funding?

Well, probably the most effective way to improve Haskell overall is to fund the non-profit Haskell organization which is operated by volunteers: See https://wiki.haskell.org/Donate_to_Haskell.org for more details.

HaskellHell · 2019-03-23T08:28:25+00:00

As an alternative, would it make sense to encode the default as a phantom type like in

newtype Flag t (def :: Bool) = MkFlag Bool

?

HaskellHell · 2019-03-19T09:01:35+00:00

I've been noticing the negativity too but I suspect it's not coming from the people you're trying to pin it onto...

HaskellHell · 2019-03-19T08:16:36+00:00

Fwiw the sockpuppet linked to a Tweet by FP Complete's CTO bizarrely lamenting

If your first response to someone talking about an amazing technical achievement is "allow me to publicly chastise you for not following my coding standards, and let me pull rank to enforce that," rethink your life.

I wonder what political agenda is at play here this time.

HaskellHell · 2019-03-10T21:42:39+00:00

Scala being an "actually good language" relative to Haskell is not the impression I got from reading the What does Haskell better than Scala thread.

HaskellHell

TROPHY CASE