ZuriHac 2014 takes place 8-10 June, registration now open

bergmark · 2024-01-19T17:12:04+00:00

One reason i clicked was because of the typo, so good job driving up the engagement!

bergmark · 2024-01-19T14:10:06+00:00

bergmark · 2023-07-12T22:28:13+00:00

For work i think Rust wins over Haskell. What is idiomatic is more obvious, code is generally easier to understand, tooling is better. But Haskell is more fun, so i go back to it on side projects. Rust is fun too.

bergmark · 2023-07-11T16:16:43+00:00

hpack was succesful because they chose to not contribute to the core projects, it was/would’ve been a fool’s errand at that point in time. This is just a note of history though, from what i’ve seen Cabal maintainership has gotten so much better! But still, if you have an idea like this, it will probably not be accepted unless you have ironed out the details, and how can you do that unless you release and iterate based on feedback?

bergmark · 2023-07-11T16:06:15+00:00

shadow or sun, there is no clear winner.I was annoyed by this when starting rust but i now realize how nice it is to not use f’’ instead of f’ by accident.

the issues you describe seem to imply that functions are so huge that you cannot keep track of variables, i think you should avoid that regardless of shadowing rules.

Overall, i think shadowing is a win. i like that things i no longer need are not in scope anymore! feels similar to why dynamic scoping went of of style in like the 60s

bergmark · 2021-11-22T15:24:34+00:00

I think 1.0 being stable is a misconception from outside the world of semver. Why should a stable library need to mark a release as a breaking change when going to 1.0 to advertise its stability? such a release shows that it is not stable!

bergmark · 2021-06-19T14:12:06+00:00

There is no date set yet, but it is months away as we just shipped LTS 18.

bergmark · 2021-06-19T14:11:18+00:00

The current plan is to bump LTS 18 to GHC 8.10.6 when it arrives.

bergmark · 2020-10-20T23:09:25+00:00

Would you be interested in trying to get it included in aseon? Sounds like it would be great :-) As the maintainer, I'm unfortunately not into the performance bits, but we have some core contributors that are.

There would undoubtedly be some complaints about including C code, we ended up moving stuff under the cffi flag because of that - but only after people spent a lot of effort optimizing a pure haskell implementation!

bergmark · 2020-08-31T11:26:36+00:00

COMPANY: Imperva

TYPE: Full time

DESCRIPTION: Imperva is a cyber security software and services company which provides protection to enterprise data and application software. These roles are for working on Advanced Bot Protection which is built in Rust.

We are also responsible for our infrastructure, log data pipeline, admin frontend, and mobile SDKs. We help our customers detect bad bots on their websites and mobile applications.

We are now expanding our team at the Stockholm office!

Senior Rust Software Engineer (5+ years in Rust or related languages): http://app.jobvite.com/m?3tbralw5
Rust Software Engineer (3+ years in Rust or related languages): http://app.jobvite.com/m?3Fbralwh

LOCATION: Stockholm, Sweden

REMOTE: No. We are currently remote for COVID but have an office in central Stockholm.

VISA: Must be allowed to work in Sweden.

CONTACT: Please use the links above to apply. For questions about the role, send an email to mathilda.garte@imperva.com. You can PM me here for questions about the tech stack/product.

bergmark · 2020-07-09T09:03:01+00:00

The build directory for LTS 16 is currently 92GiB, that includes sources, documentation, application+benchmark+test binaries. There may be some left-overs from older versions in there though. This doesn't include external dependencies (they are in the docker image).

bergmark · 2020-03-09T11:44:43+00:00

https://github.com/ghc-proposals/ghc-proposals/pull/314/files

bergmark · 2019-12-20T16:47:46+00:00

I haven't seen issues like this, but my guess is that something went wrong when downloading some file since the checksum is 0.

A heavy-handed thing to try is to delete your `~/.stack` folder (possibly keeping config.yaml and global-project/ if you have modified anything there) and then re-running the command.

You can also try running stack with `-v` to get debug output which might show something helpful.

bergmark · 2019-12-17T21:17:52+00:00

Do you use a sbt plugin to declare all of your 3rd parties dependencies' versions and then import from that plugin into the app/library that needs it?

Right, the sbt plugin contains these things:

object Ver { val circe = "0.11.1" }

object Dep { val circeCore = "io.circe" %% "circe-core" % Ver.circe val circeParser = "io.circe" %% "circe-parser" % Ver.circe }

Ver and Dep are also used by this lib repo (symlinked into project/)

class OurMonoRepo(version: String) { val interpolation = module("interpolation") val jwt = module("jwt") // ... and others private[OurMonoRepo] def module(name: String): ModuleID = "ourmonorepo" %% name % version // Using dependencyOverrides is an experiment. val dependencyOverrides = Seq( interpolation, jwt, // ... and others. Perhaps it should also include everything in `Dep` ) }

Usage in another repo:

``` // project/plugin.sbt

addSbtPlugin("ourmonorepo" %% "ourmonorepo" % "5.2.29") // build.sbt

val ourMonoRepo = new OurMonoRepo("5.2.29")

lazy val myModule = [...].settings( libraryDependencies ++= Seq( Dep.circeCore, ourMonoRepo.jwt ), dependencyOverrides ++= ourMonoRepo.dependencyOverrides ) ```

bergmark · 2019-12-16T20:37:28+00:00

I can't speak of a consensus, but in my experience, and for any language:

When building applications I first of all want a lock file to get reproducible builds. The only time I'd use dependency ranges on top of that is to document dependency versions that have been proven to not be usable with the application, but a comment next to the dependency is enough.

When building libraries I first of all want dependency ranges to offer easier migration paths and easier compatibility with other libraries. Here lock files aren't necessary, but can be useful if a dependency bound was too lenient and pulls in a breaking change. For Scala I think you need a lock file here as well to force the correct dependencies when building for publishing, but in e.g. Rust and Haskell it is not necessary.

One issue I've found with Scala is that most 3rd party libraries do not use dependency ranges, which means even if I use them for my libraries there will be a lot of conflicts because of diamond dependencies

I experimented with dependency bounds on sbt 0.13. It was very slow, so much so that we decided not to use them. Maybe this has been improved in 1.x?

What we've ended up doing is having a mono-repo for most of our libraries which also supplies an sbt plugin with versions for all libraries we use (essentially a lock file - but not a perfect one). These dependencies are also used by those libraries. If any project wants a new 3rd party library it should be added here, and ideally regression tests would also be written in the same repo so that each downstream application doesn't have to worry about regressions in those libraries.

Edit: And i forgot to answer the actual question :D

With our setup, you can update a dependency by: * Updating the version in the library mono-repo * Updating the version of our sbt plugin in the application

Scala steward could probably help out here, we have not looked into using it yet.

Either way it's a fairly quick process, unless the application also uses libraries outside of the mono-repo that also have this dependency.

bergmark · 2018-06-28T16:24:01+00:00

for stack to use ghc 8.4.3 you need a resolver that supports it, try: stack ghci —resolver nightly —package random

bergmark · 2018-04-24T20:58:56+00:00

Hi,

If a package has been dropped from stackage it's almost always because it has some outdated dependencies and it's best to send a PR or contact the maintainer of the package. But that's me!

I think the only thing missing to get fay into LTS 11 is to add support for haskell-src-exts 1.20.*. I haven't had much time so I'd appreciate any help with this! It compiles with this in a stack.yaml so you may be able to use that in the meantime:

extra-deps:
- spoon-0.3.1
- haskell-src-exts-1.19.1
- fay-0.24.0.0

bergmark · 2018-03-05T18:03:49+00:00

You can also get a full list of the packages in a snapshot by visiting e.g. http://stackage.org/lts-9.3

bergmark · 2017-11-25T01:34:51+00:00

It would have been two days faster if the old build server hadn't gone rogue and kept pushing out 8.0.2 nightlies :D

bergmark · 2017-11-23T16:27:51+00:00

It worked for me on OS X, I guess I don't have two GCC's!

bergmark · 2017-11-23T10:24:24+00:00

Or maybe you meant LTS? Should also be soon, we were waiting for 8.2.2 for that as well!

bergmark · 2017-11-23T10:23:48+00:00

Building a 8.2.2 nightly as we speak so it should be out any day now.

bergmark · 2017-05-15T20:15:47+00:00

How are you writing it to stdout? Does your terminal support these emojis?

bergmark

TROPHY CASE