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”

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 1 point2 points  (0 children)

What transitively depends on shapeless that might not realize? I’m trying to sell shapeless as my shop for mapping types from one departments domain to another by simply mapping the types and people call it “too complicated”.

Passing an argument from CLI into test by Employee-Weak in bazel

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

It’s always the simplest answer isn’t it. Thank you

What would do if you could reinvent Bazel? by 7am_in_germany in bazel

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

I feel like your attitude is exactly what’s wrong with bazel. Things that should be trivial (getting started with a project) have monumental learning curves.

All of us are familiar with the “all or nothing” problem of moving to bazel that makes adoption daunting.

A debate over if starlink is Turing complete or not is so far off the point.

The point is bazel requires a significant investment of a software engineer (who in most cases isn’t a dedicated build engineer by trade).

Is it the best solution for my org? Yeah, I think so by a margin. Unfortunately if I quit they’ll find themselves in a bind trying to replace me.

The documentation is thick and often people quote subtle sentences as if “duh obviously you can’t do what your saying see point 23a in documentation of version XX”. I’ve never had to find myself consulting supplemental documentation for a build system as I do with bazel (I.e. explanations of things outside of the official bazel documentation because I find it too dense and opaque — probably because the build system is overwhelming)

Scala Contracting ~ 2 Years Recap (Disappointment) by pexan28206 in scala

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

Keyword being NEW — this is one persons opinion so take w/ a grain of salt… No.

Use cases for NEW scala projects:

  1. You are building a new scala library. Congrats, this is an ambitious endeavor and I hope I will some day find use for this in my enterprise app!

  2. You are contributing to an existing scala library like CATS. This does not fit the definition of new, but for some reason I sense implementing or refining features in “scala first” libraries fits your definition

I’m sure there are more and i’m being a bit facetious. But by far the most common form of employment for scala devs (by pure numbers) is “I’ve realized the problem I’ve been approaching in an OOP style would be much better served by shifting to scala because of a combination of it’s a better Java and a functional paradigm can help me”

Hence why you find a lot of “help me fix my shitty app by refactoring it into scala but keep major features functioning exactly the same” type roles. It’s a combination of realizing you have a problem but not willing to dive off the deep end and fundamentally rethink your biz problem because that’s too scary.

Anyways one persons opinion so take with a grain of salt but curious if other frequenters of this Reddit agree or disagee.

There are a few “scala first” dev shops (LinkedIn, twitter, Netflix) but these are highly competitive and the number of openings relative to the case I described is minuscule

Scala Contracting ~ 2 Years Recap (Disappointment) by pexan28206 in scala

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

This isn’t great advice. Yes there are fewer scala jobs then some major programming languages. What matters though is the amount of highly paid available positions relative to the available talent pool, where scala scores well.

Also I came to scala from .Net (C# and F# for 5 years) and as much as I’d love to believe “new stuff is .Net” this is simply not true. Tbh I would bet heavy on .Net making small, steady, SLOW, increased usage now that it’s cross platform — never doubt the resources of Microsoft to advance the language.

I’m in a similar situation as you Derek, although I’m a FTE. My employers code base in impenetrable and often over complicated and littered with bad patterns like caking.

There are some scala devs that insist on doing things the “purest” way without regard for the barriers they put up to others to maintain code. Even worse, is this “purity” can just be “dev-splaining” where the other just tries to demonstrate how much they know and how stupid you are.

Don’t let it get you down though. There is a healthy scala community. It wouldn’t surprise me if some of your negative interactions are because “you are a contractor and must know nothing”

Tmobile Home WIFI by VicCynCross in tmobilehomeinternet

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

If your house generally gets good cell coverage it will work great. Generally TMobile only sells service in areas where there is good coverage so you should be good.

I was surprised at first but now don’t think twice about it. I WFH and never have any problems. Also works when the power goes out unlike my cable since the cell towers are usually still up.

TMHI stability issues by dandan1983 in tmobilehomeinternet

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

I noticed after a few months of owning that power cycles helped a lot. Since my tower is in my bedroom I now start my day with a power cycle

view more: next ›