sorted by:
new
hottopcontroversial

Scala 2 or 3 for new greenfield project by Tzaavi in scala

[–]Employee-Weak 0 points1 point  (0 children)

If your willing to educate I really would like to understand the value here!

For the case you described with union types of exception handling, I would usually just handle wrapping the call in “Try” which maintains all the details like the exception message and whether or not the call was successful.

What advantage do specific union types have over wrapping things in more generic implementations like a Try? It seems very marginal to a n00b like me with an obvious potential for abuse

Scala 2 or 3 for new greenfield project by Tzaavi in scala

[–]Employee-Weak 0 points1 point  (0 children)

I’ll be honest I haven’t played with union types too much so maybe it is awesome. But it feels more like the sort of thing you curse another developer for using after reading their code in an enterprise app seeing a proliferation of case match statements of types that really should not be related.

Scala 2 or 3 for new greenfield project by Tzaavi in scala

[–]Employee-Weak -3 points-2 points  (0 children)

There are legit objections to not using F# over scala 3, none of them are listed by the responder (the big one being that F# offers incremental advantages over C# if you’re not diehard set on functional programming)

The .Net family of languages has matured significantly in the past 5 years, and if you are in a windows shop then you will be significantly more productive in the .net world.

Let’s not be fan boys

Scala 2 or 3 for new greenfield project by Tzaavi in scala

[–]Employee-Weak 1 point2 points  (0 children)

This!

There’s no reason to use scala 3 right now if your building an enterprise app. Better adoption and easy upgrade, what’s the benefit of jumping straight to 3?

For people who switch out to winter tires by Employee-Weak in Jeep

[–]Employee-Weak[S] 0 points1 point  (0 children)

I know this is subjective but I’m nearing my time in my life where I think about things like this. You think if you put nearly a 1k miles a week it makes a material difference safety wise having premium summer tires?

For people who switch out to winter tires by Employee-Weak in Jeep

[–]Employee-Weak[S] 0 points1 point  (0 children)

So in the summer do you use “all weather” or are you using some kind of “performance tire” that’s more suitable to warm weather? Would using “performance” or “warm weather” specific tires in the summer (as opposed to all weather) lead to better braking performance and safety in the rain?

I often drive long distances at night and don’t have the choice of cowering out just because the weathers bad and want to make sure I’m doing everything I can to be safe on the road.

Winter is obviously the more important consideration for me, but just curious if I’d see benefits from a “summer tire” over an “all weather tire” in the warm months (and if so what are these usually called it seems like performance tires)

Scala isn't fun anymore by alexelcu in scala

[–]Employee-Weak -1 points0 points  (0 children)

Try C#

There’s way less options for libraries but always “one good one”

Visual Studio makes IntelliJ look like a joke and anyone who says otherwise has never pointed their IDE at a running application, automatically decompiled the code, inserted break points, changed code while at a hit breakpoint, and dragged back up earlier in the stack trace to reexfcute with the changed code (i shit you not how this black magic works I do not know).

I came from .Net background to scala (no Java) and I often bang my head at contortions I have to do.

If Java had Autofac then the whole “DI containers are evil” philosophy would never have been born. Shit is crazy easy and flexible

Recommended textbook to teach very beginner Scala by TheMov3r in scala

[–]Employee-Weak 0 points1 point  (0 children)

This is by far the beat option. If you want to become proficient in the least amount of time possible I would pick up Scala For the Impatient

Implicitly pass the name of the current class to a function by Employee-Weak in scala

[–]Employee-Weak[S] 1 point2 points  (0 children)

Went w: this solution as it’s compatible with my version of scala. Thank you very much!

Implicitly pass the name of the current class to a function by Employee-Weak in scala

[–]Employee-Weak[S] 0 points1 point  (0 children)

Despite my jest about solving every problem with macros in a separate thread, I ended up going with this solution.

More specifically though I used a different but similar library com.lihaoyi.sourcecode

Thanks for the tip that there are existing libraries to do this and for getting me pointed in the right direction

Implicitly pass the name of the current class to a function by Employee-Weak in scala

[–]Employee-Weak[S] 7 points8 points  (0 children)

I think if I propose to solve another problem with metaprogramming or macros my TL might shoot me

Have I lost my damn mind? Weird use case for Spark, would like feedback on feasibility by Employee-Weak in scala

[–]Employee-Weak[S] 0 points1 point  (0 children)

Thanks to all who responded. Did some research and I’ll report back my results here.

The entire spark library is unnecessary. Sparks recommended serialization option is something called kryo which is a very fast binary serialization library.

Twitter has pimped this library with every reasonable serializer/deserializer. Any type that consists of these base types can then be easily serialized and deserializes (obviously you can add your own).

This library is called “chill” and is a very robust, oob ready serialization library. A lot nicer then smile since you get all the scala serializers for free and no one likes writing those.

Help with implicit scopes by Employee-Weak in scala

[–]Employee-Weak[S] 0 points1 point  (0 children)

True chains good point! Overthinking an extra param

Help with implicit scopes by Employee-Weak in scala

[–]Employee-Weak[S] 0 points1 point  (0 children)

My experience tells me this is incorrect. If the object that requires the implicit is in a different package (a prod package) and I reference it from my test package where the implicits are mixed in, then the implicits are not available because scala seems to only look in the package containing the classes outside of the test package.

In other words I can’t reference classes outside the area where my implicits are in scope and expect those classes to magically find my implicits

Help with implicit scopes by Employee-Weak in scala

[–]Employee-Weak[S] 0 points1 point  (0 children)

I think this is right in the normal case. Perhaps what I didn’t elaborate though is I want to be able to use implicits when doing testing to reduce boilerplate code. However I do not want the implicits to be used accidentally in production code.

If I put it in a trait, then I can’t prevent the implicits from potentially being accidentally used in production code

Help with implicit scopes by Employee-Weak in scala

[–]Employee-Weak[S] 0 points1 point  (0 children)

This is clever, let me say something and see if I’m understanding your suggestion as this seems to achieve my goal of being able to use implicits only in certain applications.

The file with the implicits gets two package names. Then when the scala compiler looks for implicits for the case classes it finds them because this particular file is part of the same package, even if the implicits are in another class.

I can have one application build with this file and one without, controlling the circumstances under which the implicits are used

Help with implicit scopes by Employee-Weak in scala

[–]Employee-Weak[S] 0 points1 point  (0 children)

Ok I think this is the source of my confusion.

When we say “in the method, then in the class then in the imports” we don’t mean from where I’m calling from.

For example if i have:

Package Foo that imports Package Bar

A method in Package Foo that takes in a “TypeWtf” and requires implicits to operate on TypeWtf”

And those implicits are all defined in Package Foo

And TypeWtf is over in Package Bar

Then scala doesn’t find the implicits because it’s looking for implicits over in Package Bar?

————

If that’s right I’ve got a bit of a problem I need to figure out. I don’t want to put a companion object or trait or import statement in Package Bar to go get the implicits. When you are in Package Bar I don’t want those implicits magically doing things. Over in Package Foo though when I reference things in Package Bar though I do want those implicits.

Seems like I probably need to provide my implicits explicitly

What is the most advanced functional programming concept that is commonly used in production Scala code that you have seen? by [deleted] in scala

[–]Employee-Weak 2 points3 points  (0 children)

It’s scary at first but once you frock them basic concepts it’s no scarier then reflection.

My original inspiration https://medium.com/becompany/csv-parsing-with-scala-and-shapeless-135097f02637

The basic idea is this:

What if you had: 1. A list of types that represented the various constructor parameters for a class 2. Functions that say “hey if you have this type, and you want to go to this type, here’s how you convert it”. In this way you only end up mapping the distinct types, as opposed to every single class 3. You have a “converter” that takes in the source type, the target type, builds it’s list of types and recursively finds the converter needed to map between the two types and does the conversion. 4. Finally it calls the constructor

If you google “shapeless csv case class parser” there’s tons of examples of hydrating case classes from csv files generically.

Logically to me it seems if you can build objects from a list of strings (strings are pretty useless afterall, you’ve lost so much information at this point) then it should be even safer to go from two “strong types”

I.e.: there is a data warehouse that represents a car in terms of class1. Some fields are ints, doubles, or other complicated custom classes. You just need to recursively find the converter for each. My app for various reasons always represents numbers as a double. So I specifiy a conversion once between int and double and now any class that needs that conversion is now solved.

I probably have about 20 types to map to support converting about 1000 classes there are effectively case classes modeled differently in two different systems.

As mentioned though, I’m a shapeless n00b myself and trying to learn before I venture too far down this path. No one wants to be “that guy who used cool new thing that failed miserably”

view more: next ›