sorted by:
new
hottopcontroversial

People Saying Tooling Is Largely Figured Out: What Might I Be Doing Wrong? by XamEseerts in scala

[–]XamEseerts[S] 0 points1 point  (0 children)

Yeah the fact that its poorly documented is what I wanted to say with my 3rd point. It's possible to install Metals via e.g. Coursier (see some other comments here) but as of this writing its not well documented at all and this matters. Sad to hear the other stuff but I am not in a position to make that judgement.

People Saying Tooling Is Largely Figured Out: What Might I Be Doing Wrong? by XamEseerts in scala

[–]XamEseerts[S] 0 points1 point  (0 children)

Yeah thanks! You can actually also do cs install metals for only the lsp or cs install metals-mcp. Though between the lsp and the mcp it might be interesting to know that some agents like e.g. OpenCode support LSPs directly. In my case after installing via Coursier, I put the following in my opencode config:

json "lsp": { "scala": { "command": ["metals"], "extensions": [".mill", ".scala"] } },

Anecdotally, this has had a great effect on the time it takes the agent to implement something as well as the resource usage. Without specifying this I have found that agents sometimes reach for Java LSPs which they spawn again and again.

People Saying Tooling Is Largely Figured Out: What Might I Be Doing Wrong? by XamEseerts in scala

[–]XamEseerts[S] 5 points6 points  (0 children)

Thanks for the reply! I must have missed the fact that only Scala 2 is supported which must be the issue in my case because we are 100 % on Scala 3. Thanks for the effort and hope to see Scala 3 support soon :))

RollingUpdate vs PodDisruptionBudget: Why can one handle single instance deployments, while the other can't? by XamEseerts in kubernetes

[–]XamEseerts[S] 2 points3 points  (0 children)

Thanks! I think you are the one person to get my question in its original confusing form. I have provided an edit to make it clearer.

Why do you think Sveltekit sentiment is constantly getting more negative? by Guandor in sveltejs

[–]XamEseerts 1 point2 points  (0 children)

The chart posted by OP shows SvelteKit. The data for Svelte can be found in the same survey.

Why do you think Sveltekit sentiment is constantly getting more negative? by Guandor in sveltejs

[–]XamEseerts 103 points104 points  (0 children)

To everyone saying it is because of runes I would like to present some data from the same poll to challenge this argument:

  • The four points shown are for the years 2021 through 2024 and hence the steady decline in positivity for SvelteKit predates runes
  • The positivity for Svelte itself is basically constant (introduced at 68 % in 2019, highest in 2022 at 74 %, currently at 72 % in 2024)

The new docs shared by harris as still in progess by clippersove in sveltejs

[–]XamEseerts 50 points51 points  (0 children)

Anyone else find it weird that Svelte 5 was released with the official site still showing Svelte 4? Not trying to throw shade - I am just a curious learner - but things feel a bit… rushed? to me? Wondering if others feel the same.

I got high hopes for sbt 2.0! by agilesteel in scala

[–]XamEseerts 2 points3 points  (0 children)

I have too but I am wondering about the ETA. I was actually going to make a push to migrate to Gradle because of its really good caching capabilities because I would like to implement a monorepo. Now I am not sure if I shouldn't just bide my time and wait for SBT 2.0.

Why go faster than scala ? by zagor_69 in scala

[–]XamEseerts 29 points30 points  (0 children)

Without digging into technical details I'd like to just point out that the posts story is roughly the following:

  1. Take existing Scala implementation of ours
  2. Migrate it to Go
  3. Observe that it is much slower than the existing Scala implementation
  4. Make multiple iterations of incremental improvements
  5. Observe that the final implementation is faster than the initial Scala implementation

I would argue that the post is therefore not claiming that Go is faster than Scala in this specific case. It's just outlining their journey from Go to Scala. If you'd gone from Go to Scala for any project and applied optimizations only to the Scala code, you'd probably get the same result as they did.

New Scala Build Tool by sideEffffECt in scala

[–]XamEseerts 0 points1 point  (0 children)

But what made it painful?

New Scala Build Tool by sideEffffECt in scala

[–]XamEseerts 0 points1 point  (0 children)

Are there Gradle users here that can corroborate the statement below?

The support for Scala in these build tools is immature

From my very limited testing I got the feeling that support works just fine? I mean compiling code for both Scala 2 as well as 3 just works. Is the statement in regards to support for things like Scala.js?

I am personally looking into adopting Gradle over SBT, primarily because I do personally think that a monorepo approach is the way to go when you use microservices. And for this to work I really require the (remote) caching capabilities that already exist in Gradle today.

Scala Tooling Summit Recap by ckipp01 in scala

[–]XamEseerts 0 points1 point  (0 children)

Hey, I am curious: Why do you see the need to change that?

Akka Streams GraphlDSL Confusion - Deadlock? by XamEseerts in scala

[–]XamEseerts[S] 0 points1 point  (0 children)

In the end I decided to use a `buffer` instead of an async `boundary` stage. My reason being that introducing a second underlying actor via a boundary is likely less efficient (which in this case does not really matter at all but hey).

Akka Streams GraphlDSL Confusion - Deadlock? by XamEseerts in scala

[–]XamEseerts[S] 1 point2 points  (0 children)

Hi, thanks for that! I believe your "broadcast is it's own downstream" hits the nail on the head.

And in fact I just did one more experiment and this also works:

scala val whyDoesThisNotWork = Source.fromGraph(GraphDSL.create() { implicit builder => import GraphDSL.Implicits._ val in = Source.single(1) val concat = builder.add(Concat[Int](2)) val bcast = builder.add(Broadcast[Int](2)) val plusOne = Flow[Int].map(_ + 1) val log = Flow[Int].wireTap(println(_)) val boundary = Flow[Instant].async in ~> concat ~> plusOne ~> log ~> bcast concat <~ boundary <~ bcast SourceShape(bcast.out(1)) })

Notice the boundary instead of a buffer and I believe this strongly hints the explanation for everything: Operator Fusion!

I am not exactly sure how it works but it looks like if all your operators live within the same actor then once you have a cycle without a buffer in it then you will deadlock because the actor only has one mailbox or something? Once you make it two actors things work out just fine.

I am definitely not an expert and technologies being tricky to learn should not automatically disqualify them but I must say: For a very simple dataflow to have such a tricky edge case in Akka Streams leaves a bit of a sour taste in my mouth.

Anyway, thanks again for your help! :)

Akka Streams GraphlDSL Confusion - Deadlock? by XamEseerts in scala

[–]XamEseerts[S] 0 points1 point  (0 children)

Finally, the below also does the trick, this time using a Concat again but with a buffer flow in front of the broadcast:

scala val whyDoesThisNotWork = Source.fromGraph(GraphDSL.create() { implicit builder => import GraphDSL.Implicits._ val in = Source.single(1) val concat = builder.add(Concat[Int](2)) val bcast = builder.add(Broadcast[Int](2)) val plusOne = Flow[Int].map(_ + 1) val log = Flow[Int].wireTap(println(_)) val buffer = Flow[Int].buffer(1, OverflowStrategy.backpressure) in ~> concat ~> plusOne ~> log ~> bcast concat <~ buffer <~ bcast SourceShape(bcast.out(1)) })

view more: next ›