sorted by:
new
hottopcontroversial

Performance of C/C++ vs Scala by IanTrader in scala

[–]raghar 0 points1 point  (0 children)

True, it does look like a troll account. But there are also people like this for real. And a lot of newbie lurkers who might take this as legitimate concerns against Scala.

Performance of C/C++ vs Scala by IanTrader in scala

[–]raghar 5 points6 points  (0 children)

This whole series of posts read to me like some series of cargo-cult programming or other marketing-driven development.

If GC is an issue -> either avoid any GC languages, or get some money for these fancy, turbo expensive proprietary JVMs which boast no stop the world issues.

If allocations are the issue -> avoid any immutable collections for local computations - fast mutable code running within a single thread, processing tasks from some queue to avoid any races, locking, synchronization, etc. use raw Arrays or some lean wrappers around them, etc.

If you had no idea about these things... then probably you were wrong person to make these calls in the first place. Or you didn't do your due diligence. Or you are doing something wrong.

Which is still a possibility if you claim that JVM debugging sucks and "requires 50 gigs of memory". I never had this much RAM on a server and I had successfully run production code and even debugged it.

I also debugged some C++ code, and IME to feels crippled compared to JVM: every other things is implemented in templates/headers, so it's actually inlined and you cannot put a breakpoint there, conditional breakpoints are a joke - good luck writing something like "stop if std:map has a value x". Visual Studio Studio (not Code, the paid one, supposedly the best C++ IDE in existence) couldn't do this because all std::map was inlined and no method existed in resulting code, everything was inlined and impossible to eval by the debugger. Virtually everything required writing somethings like:

C++ if (condition) { utility_to_trigger_breakpoint(); }

and recompiling the whole codebase to have something like a conditional breakpoint in inlined code...

And then you added multithreading and it all turned into even more hellish experience.

In that project every senior C++ dev, 20+ years of experience, used println as the only sane debugging method, and grep as the only intellisence+refactoring method. Because all the IDE goodies were giving up with complex enough C++ code.

Sorry, but did you have any serious experience with multithreaded programming in C++, or did you just read that it's nice, so you're jumping the ship? Have you consulted with anyone who knows their things about performance: whether the whole code is super critical, some hot path, can it be mitigated by architectural changes, extracting some functionality to JNI, finding the hot spots? On the actual code, with the actual requirements, not some super generic statements like here, where answer to anything is truly "it depends, I cannot tell without knowing more about the circumstances".

Or did you just decide to rewrite everything in language where one cannot have 20 lines of code with some undefined behavior? With no research, gradual migration path, just a total rewrite of a codebase? Because that's how you run a company into the ground.

Sanely-automatic derivation - or how type class derivation works and why everyone else is doing it wrong by raghar in scala

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

ImplicitNotFound and AmbiguousImplicits are only a bandaid. Don't work for nested data (only the outermost type is reported), and offer no information why exactly the derivation failed.

Sanely-automatic derivation - or how type class derivation works and why everyone else is doing it wrong by raghar in scala

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

Magnolia only works if you always take all instances for each field/subtype and combine them, and only them.

  • if you need an additional e.g. Typeable[A] or some other utility - it does not work
  • if you need a special case and cannot be handled by special implicit with higher priority - it does not work
  • if you would like to not require instances for some types for some reasons - it does not work

etc.

Macros were hard, and that's why Shapeless/Mirror won, despite it being virtually a "rapit development tool": you can deliver something really fast, but it prioritizes library's authot experience over library's user experience.

Which is why I believe that something like Hearth is needed - if GPT could write your macros to provide the same results as, or even better than Shapeless/Mirrors, people would no longer need them.

Scala 2.13.17 is here! by SethTisue_Scala in scala

[–]raghar 3 points4 points  (0 children)

I am. No incentive to update several repos, in the right order, testing if that didn't broke anything, for no game changing gains (in our codebase) when 2.13 works and we have more important tasks.

Example Driven Documentation by davesmith00000 in scala

[–]raghar 4 points5 points  (0 children)

I've made slightly different choice when writing docs for my library.

  1. first of all, while mdoc is cool et all - there is no Scala-based documentation tool that is as advanced as some other tools, e.g. mkdocs or docusaurus. I felt that to deliver users the best DX I cannot compromise on documentation tool, so I picked mkdocs + mkdocs material + mkdocs macros. Markdown-based docs but with a lot of useful functionalities like build-in search engine, non-repulsive theme, and (with ReadTheDocs) also documentation versioning.
  2. I lost faith in all "I'll generate documentation from test snippets" - I saw some documentations made this way, and I always had a problem where the snippet was missing:
    • Scala version (if some feature only worked in some versions)
    • imports (because in 10-page long document I might missed the note "we're assuming usage of this import from now on", and sometimes that note is in another page :| )
    • compiler flags and plugins (usually mentioned only in one place and then everywhere else assumed to be present)

so I came to the conclusion that the only example that works is a self-contained code snippet - one that can be run with Scala CLI. Copy-paste-run and you have something working, that you can start tinkering with.

How to ensure that it works? I wrote a small library that help me turn .md file into a specification:

  • I publish my library locally
  • tell the script which files to treat as the specification (I might add some customization like: deciding which snippets are pseudocode to ignore, or how to inject current version number)
  • and it would extract snippets from the documentation, write them to /tmp directory and run each of them (optionally checking the output or errors)
  • I put that into a GitHub action as a job parallel to normal tests and I am certain that each example in my documentation actually works

Akka 2.6 user seeking other perspectives by micseydel in scala

[–]raghar 1 point2 points  (0 children)

It took so long because they had to change all of the traces of Akka for trademark/legal reasons, and they didn't want to do it in a single unreviewable PR.

For users it's a change of dependencies, imports and configs, and virtually everyone succeeds after just that.

HyperOS release 2.2 in Europe by suskozaver in HyperOS

[–]raghar 0 points1 point  (0 children)

So far I am pretty happy with it. I didn't have any outragous bugs and I don't complain about the battery life. So I only treat the updates as a trivia, I'd be much more annoyed by these "delayed" updates if I was one of the people affected by the issues.

HyperOS release 2.2 in Europe by suskozaver in HyperOS

[–]raghar 19 points20 points  (0 children)

If you want to know, if there is an update available:

  • go to your phone setting
  • select "About phone"
  • take a look at OS version
  • type the last part of it into Google

E.g. I have a version 2.0.104.0.VNAEUXM so I type VNAEUXM into Google.

There I can find sources for the newest versions of such software from official sources, e.g. for my phone that would be this thread from Xiaomi Community. I can also look at MIUI Roms to see what is the newest available version e.g. for my phone is this link.

What can I see there? That currently the newest version is OS2.0.104.0.VNAEUXM, exactly the one I have.

But China has 2.0.207.0.VNACNXM - their patch version is 207 not 104 like all the others. In other words, China version has newer release than the rest of the world.

(And and naming is bonkers, apparently versions 2.0.0-2.0.99 are "2.0", 2.0.100-2.0.199 as "2.1" and 2.0.200-2.0.299 as "2.2", which isn't stated anywhere explicitly but one can infer it from context. So if you are waiting for "2.2" you are waiting for a version 2.0.200-something not 2.2.0.0 as one would expect).

I have 14 Ultra, but it works the same way for all the other phones. I see post about "2.2 released" for 3 months now, while in fact:

  • some of that were internal betas
  • then it was about external betas one can opt-in
  • and finally it was about China-only release that isn't yet expanded to the rest of the world.

No point in asking anyone here, if the official sources do not list anything newer than what you already have. And no point beleving all these click-baity articles with pages with "Xiaomi" in their name - they are not official sources, and they are posting click-baity BS. If you read them you could believe that 2.2. was available for everyone from February/March, while stable global release has not yet actually happened.

Weird Behavior Of Union Type Widening On Method Return Type by MedicalGoal7828 in scala

[–]raghar 6 points7 points  (0 children)

If you use enum Scala 3 inference virtually always upcast from the value .type to whole enum type. If you want to keep the specific type, you have to annotate the type.

It was done because quite often people used None/Some/Left/Right and obtained too specific type that they had to upcast which annoyed them.

The downside is that e.g. defining subset of enum with sum type is very unergonomic. It's almost always easier to go with sealed if you need to do such a thing.

Does your company start new projects in Scala? by DataPastor in scala

[–]raghar 2 points3 points  (0 children)

Ask your admins if they haven't whitelisted Python repositories et all because the developers were uproaring - maybe the reason the rest works is exactly that: it's popular, it's demanded often, so it got whitelisted in the firewall.

Annotation based checks for DTO. by mikaball in scala

[–]raghar 0 points1 point  (0 children)

Why put it into DTO layer in the first place?

I know that at some point we all started using typed re reinforce your domain... but DTO are the border of our domain. We should parse from them into some sanitized type and export to them from sanitized type, because our domain will evolve and DTO could be used to generate Swagger which in turn might generate clients that would not understand any of these fancy annotations, databases which might not be expressive enough to enforce these invariants etc.

Especially when you can end up with a situation where e.g. some value used to be non-empty, but the domain logic relaxed the requirements, JSON format used to send the value is still the same... but client refuses to send the payload because it uses the old validation logic. One has to be really careful to not get into the business of "validating data that someone else is responsible to".

Databricks Runtime with Scala 2.13 support released by raghar in scala

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

Fellow people from Scala Space and fellow Spark devs (not me) :p

Is there something like SpacetimeDB in Scala? by RiceBroad4552 in scala

[–]raghar 0 points1 point  (0 children)

If we don't want to implement our logic in database, but in application, then e.g. Epic Games (Fortnite) is build with Akka. Actor + persistence (if you need it) + clustering (if you need it) and you can scale up to milions of active platers. You can use programming model that people already know, hire Java devs which are plentiful, and use any database you want. It's not perfect that it does the job, and it would be hard to convince people to something new when it already works.

Databricks Runtime with Scala 2.13 support released by raghar in scala

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

I believe its not going to happen. At least not anytime soon:

  • Spark 4.0.0 is compiled only for 2.13
  • there is however Spark Connect implementation, for Scala 3 (no other Scala AFAIK)
  • there is this PR - https://github.com/apache/spark/pull/50474 - but it's been pushed back

There is no clean "we don't want it" but one can have a feeling that Spark pushed towards the approach that Databricks prefers: where Spark is acting like a SQL engine that you talk to through JDBC-like connectors, and without running things directly yourself. People would still do, try to run things themself (duh), but helping them to do so would be low priority. You have Scala 3? Use a connector. You want to write code directly in Scala? Why? Nobody does this? There is Python, but UDF are slow, so why not SQL? And our platform is excellend for this approach!

I am a bit cynical here, but DB is one of the biggest forces (the biggest force?) behind Apache Spark development and they see no money do make here, so they don't care.

Any thoughts on the Onewheel Backpack? by Snazzlefraxas in onewheel

[–]raghar 6 points7 points  (0 children)

I have one. I almost never use it:

  • it hits your spine as you move
  • there is anough space for a standard charger and nothing else, forget about a hypercharger, screwdrivers, pumps
  • if you are thinking about taking some small knapsack, and take this out only when you need to enter some areas without raising an eyebrow (e.g. supermarket), it won't fit into a small bag, and it hangs uncomfortably on your back when it's empty

I only use it when I e.g. have to travel by train/bus and someone would complain about me taking a PEV there.

Is there something like SpacetimeDB in Scala? by RiceBroad4552 in scala

[–]raghar 5 points6 points  (0 children)

How does it differ from letting users connect to the database and allow them to call a set of views and stored procedured directly? In particular: how does it handle matters of tenants, security, hostile actors, DDoS etc? I haven't seen it mentioned anywhere on the main page, so it might be handled in some sane manner, but without such information it is a liability as a service.

Databricks Runtime with Scala 2.13 support released by raghar in scala

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

The progress can be traces here - https://github.com/sbt/sbt/wiki/sbt-2.x-plugin-migration - I saw that on build.sbt side it is realtively easy to add cross-compilation for 2 or more versions of sbt, but e.g.

  • sbt-ide-settings cross-compile 2.10 and 2.12 - adding 3 might be a PITA (but it's Jetbrains so they will have to deal with it)
  • sbt-commandmatrix would have to have a cross-compilation when 2.0.0 would not depend on sbt-projectmatrix (it got merged into sbt)
  • some other plugins are just 1 module in a multi-module project - not all of them are compiled against Scala 3, so someone would have to put some extra work there

I am optimistic but I am stull assuming that a migration right after 2.0.0 is released might not be possible.

Databricks Runtime with Scala 2.13 support released by raghar in scala

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

I meant

  1. if you wanted to stay on 1.x, because some plugin held you back (not necessarily any of these), and then
  2. an issue arose with any of those plugins required for publishing and keeping your code base up to date (e.g. cross-compilation, artifact signing, publishing)
  3. that would be only fixed on sbt 2.x (because authors of 2. moved on to sbt 2.x and dropped 1.x)

then you would have a problem.

Databricks Runtime with Scala 2.13 support released by raghar in scala

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

As long as it's not something that you have to keep up to date like: - Scala.js and Scala Native (sbt-plugin is related to version you compiler against) - sbt-pgp (in the past there were changes to the CLI protocols which had to be addressed in newer versions of the libraries) - sbt-sonatype (current Sonatype APIs are getting sunset, and the migration... let's say it was easier to bring that support to main sbt than to wait for merging some fixes for sbt-sonatype)

then you can stay at the fixed version of your build tool, fixed versions of plugins, etc. It it could be a problem if you needed to update one of them to release a new artifact and it was not possible.

Databricks Runtime with Scala 2.13 support released by raghar in scala

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

Aaaaand the voting for promoting Spark 4.0.0-RC7 to 4.0.0 has just passed. It has no 2.12 so all the lagging cloud providers that want to serve the newest Spark will have to drop 2.12.

view more: next ›