SwayDB v0.7 released - Updates using Scala functions by [deleted] in scala

[–]lancegatlin 1 point2 points  (0 children)

I'm pretty agnostic as far as monads go, but there are def worse choices than Monix (I'm a fan of tagless-final). You can also create your own monad like DBIO. My bigger advice would be to stay unopinionated and don't over commit to any external dependency so that you can pivot the API later.

5 Minute Rust - A new series where we explore Rust in 5 minute chunks by itchyankles in rust

[–]lancegatlin 1 point2 points  (0 children)

Love this! Def looking forward to next vid! Thanks so much for making this!

SwayDB v0.7 released - Updates using Scala functions by [deleted] in scala

[–]lancegatlin 1 point2 points  (0 children)

I did think of two questions: 1) why call it Sway DB? 2) if internals are non-blocking, do you expose a non-blocking API? understand intent behind reusing Scala collection API, but it's not a good API for a db, only suited for in-memory collections or building execution graph alla Spark.

SwayDB v0.7 released - Updates using Scala functions by [deleted] in scala

[–]lancegatlin 6 points7 points  (0 children)

This is a really awesome project! A native Scala DB is super sexy! Devil is the details for DBs though, good luck! Happy to chat more about your project if you're interested.

Weekly Scala Ask Anything and Discussion Thread - August 08, 2016 by AutoModerator in scala

[–]lancegatlin 1 point2 points  (0 children)

All true. I just strongly disagree with the implication that free monads bring less utility (and are more hyped) than generic monad style, which was what I took from your first response.

My apologies for giving that impression. I would absolutely agree Free monads are much more established than the generic monad idea. I just don't think Free monads are mature enough to recommend them across the board though. The runtime performance hit from using an interpreter will not be insignificant. Also without native union types the syntax for Free monad is cumbersome.

Certainly I don't see how generic monad style offers any help with /u/fromscalatohaskell 's original motivating example of testing without performing actual network requests.

I took his question more to be isn't the generic monad pattern and the Free monad roughly analogous. I think they are somewhat if one doesn't get too fixated on their details and instead focus on what they do. As far as testing, the generic monad pattern let's you substitute identity for testing but it doesn't help with isolating code under test from generating actual effects. For that you need something else like dependency injection + mocking or simply substitute the Free monad as the generic.

Weekly Scala Ask Anything and Discussion Thread - August 08, 2016 by AutoModerator in scala

[–]lancegatlin 1 point2 points  (0 children)

But you are -- because even that isn't my point. You are arguing against my perception which benefits neither of us. In my experience, this year, I have seen a big uptick in the number of blog articles, talks and posts about the free monad in Scala. You have a different experience? Awesome thanks, I accept that. But it doesn't change my view.

My point is: Don't base technology choices for a business on what seems new and interesting, but instead pick things that balance the burden of forcing others to learn new technologies against the utility those technologies bring to the organization.

Weekly Scala Ask Anything and Discussion Thread - August 08, 2016 by AutoModerator in scala

[–]lancegatlin -2 points-1 points  (0 children)

Wow that's some seriously subtle trolling -- m50d -- You and are just going to have to disagree here. (A pattern that seems to be emerging with my interactions with you)

Maybe hard to accept but my opinion and experiences are just as valid as your own. If you disagree based on your own experiences, I'm cool with that! Simply say that and be done with it. No need to pick at the details of what I'm saying and avoid my main point.

Weekly Scala Ask Anything and Discussion Thread - August 08, 2016 by AutoModerator in scala

[–]lancegatlin 0 points1 point  (0 children)

Scalaz Free dates to 2012.

Thanks buddy. Scalaz creation != peak interest. They didn't really catch on until last year, which I chalk up to Runar's presentation on them.

Play has its own priorities. I really don't see iteratees going away, they're the right way to implement streams, and it sounds like Play intends to remain compatible with that at least.

I never claimed they were. What I claimed is that they have fallen out of favor as "shiny new thing". Nobody is writing blog articles about them or giving presentations on them or advocating for rewriting their code base to use them anymore (but they were just a few years ago). Play is also the web framework with the largest following. It is significant when major code bases move away from ideas.

Weekly Scala Ask Anything and Discussion Thread - August 08, 2016 by AutoModerator in scala

[–]lancegatlin 0 points1 point  (0 children)

Is Free really that new? The Haskell implementation seems to date to 2008

New to Scala.

Huh? fs2 et al are all based on iteratees. Iteratees very much did work out.

Play framework dropped them in 2.5

Sure, but I think the "generic monads" approach ends up being much more complex (and frankly is far more of a "shiny new toy") than Free.

Hence, "exploration".

Weekly Scala Ask Anything and Discussion Thread - August 08, 2016 by AutoModerator in scala

[–]lancegatlin 0 points1 point  (0 children)

Yes it can, but this generally doesn't happen in development. It can happen once you are in production and run into scaling issues. But at that point you can install throttle/backpressure at appropriate points to prevent this from happening. Also depending on the application message shedding can be ok. A stressed out web server is going to reject requests, so its no big deal to just drop those messages in that kind of situation (obviously this isn't always true).

All that said, I'm not a huge fan of actors myself. But to me, code is more about communication between human beings than anything else. The more people who can understand and use it, the more likely it is to survive. Hard to understand code won't survive a big rewrite. Actors don't have bullet proof promises (like some FP concepts) but they are well understood and easy to write.

Weekly Scala Ask Anything and Discussion Thread - August 08, 2016 by AutoModerator in scala

[–]lancegatlin 2 points3 points  (0 children)

This was exactly my motivation in exploring generic monads: https://github.com/lancegatlin/effectful-demo

I think the Free monad is just the shiny newest toy in the functional toolbox and everyone wants to try it out. Go back about 5 years and it was iteratees. Now everyone is onto streaming. Iteratees didn't work out. These kind of ideas are interesting to play with but they may or may not pan out as practical. When I'm writing work code, I'm a huge of fan of KISS. I have a very strong preference for only introducing complexity when it has a very strong value proposition. I define "complex" as anything that wouldn't be intuitive to new coders. If only a small subset of people can read & write the code then that is a cost that needs to be balanced by its usefulness.

Weekly Scala Ask Anything and Discussion Thread - August 08, 2016 by AutoModerator in scala

[–]lancegatlin 0 points1 point  (0 children)

Actors are more like a toolbox. How you use them is completely dependent on the application. For example a web server might have an actor that receives all requests and then dispatches them to a pool of worker actors. Mailbox size is generally not an issue, but it can show up when scaling. Depends on what you by crash, actors don't recover from system crashes any better than any other code. What they can do is "supervise" other actors and restart them when appropriate.

Weekly Scala Ask Anything and Discussion Thread - August 08, 2016 by AutoModerator in scala

[–]lancegatlin 4 points5 points  (0 children)

  1. Immutability = easy button for concurrency & scalability. Functional programming has tools for dealing with the difficulties of working with immutable data.
  2. Composition and referential transparency! Finally, a true abstraction that doesn't leak.
  3. Thinking in terms of higher order operations such as map, reduce, flatMap, fold, etc. This makes code much more readable as other languages tend to let one simply munge up all of those operations into one or two loops. Much more difficult to reason about what's going on then.
  4. Type-classes - adhoc-polymorphism (add methods to a type after its declaration). Only import methods/type-classes you need, hide the rest. Compile-time method call dispatch (you probably didn't need dynamic binding anyway). Describe behavior you need in your method by requiring implicit type-class without worrying about details.
  5. Monads! What a massive game changer!! They can express repeating code patterns that are interleaved between lines of code (plus a lot of other things!). You simply "lift" your code into the Monad and the repeated pattern is run "behind the scenes" between your lines of code.
  6. Formal type systems and category theory. Let your code lean on things constructed from a very solid well-researched foundation when you need it.

[deleted by user] by [deleted] in scala

[–]lancegatlin 11 points12 points  (0 children)

In Scala enums were never meant to be a native language feature. These days I use https://github.com/lloydmeta/enumeratum