scala-trace-debug VS dotty

If you're not sure what you want to do maybe build your own sample site from a "starter" like https://github.com/microsoft/TypeScript-Node-Starter (this one uses TypeScript which is JavaScript with types added) or https://github.com/sahat/hackathon-starter (this one uses plain old JavaScript without types). I personally deploy to https://www.heroku.com/ because it's less complicated than deploying to AWS or Google Cloud but more businesses deploy to AWS than Heroku so learning AWS and having the AWS services you use to build and deploy your app as skills on your resume would probably make your resume look better to companies than just saying you know Heroku. If you want to copy off me (don't make and use an exact copy) my sample app deployed to Heroku has its code at https://github.com/JohnReedLOL/TypeScript-Node-Starter and the site is at https://sea-air-towers.herokuapp.com/ (I pay Heroku $7 a month for hosting). It's good to have a link to a sample app and link to the code for your sample app on your resume, just make the README.md file on GitHub look good so people can look at it and know what your app does. I have a software library with a much better looking README.md file at https://github.com/JohnReedLOL/pos

Dotty? Was it still the name later?

http://dotty.epfl.ch/

I think this might be related to this issue.

You can look (and EPFL collect feedback) about EPFL implementation of async/await: https://github.com/lampepfl/async. Also you can look at dotty ticket about this: https://github.com/lampepfl/dotty/pull/16739

The reason I’m not currently an opaque type user as they do not play well with the tagless final style we use, though I am patiently awaiting some attention on my bug report: https://github.com/lampepfl/dotty/issues/17281

Links: - https://dotty.epfl.ch/ - https://scala-native.org/en/stable/ - https://www.scala-js.org/ - https://typelevel.org/ - https://zio.dev/ - https://github.com/scala-native/scala-native/pull/3120 - https://github.com/lampepfl/dotty/pull/16517 - https://dotty.epfl.ch/docs/reference/experimental/index.html - https://scala-cli.virtuslab.org/ - https://scalameta.org/metals/ - https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html - https://www.scala-lang.org/blog/2023/04/18/faster-scalajs-development-with-frontend-tooling.html - https://www.scala-lang.org/blog/2022/08/17/long-term-compatibility-plans.html

Scala Native has much more control on how the Scala AST is compiled, and can easier workaround platform limitations, eg. lazy vals in Scala 3 required reflection config for Native Image (see this and that), while in Scala Native we could mitigate problems with unsupported usage inside in other ways within the compiler plugin.

By the way, you might be interested in this recent PR which overhauls the scala 3 macro docs: https://github.com/lampepfl/dotty/pull/17060.

For example, this issue (https://github.com/lampepfl/dotty/issues/12840) was blocking the migration, it was reported more than a year ago and the fix was finally released a month ago (https://github.com/lampepfl/dotty/releases/tag/3.3.0-RC2).

For the record, there is an implementation of :javap which is close to being done but might need a volunteer to get it over the finish line: https://github.com/lampepfl/dotty/pull/12210

im glad to tell you that in 3.3.0 a lot of these -Wunused lints will be supported: see https://github.com/lampepfl/dotty/pull/16157