pekko
questionable
pekko | questionable | |
---|---|---|
8 | 3 | |
1,074 | 114 | |
4.8% | 3.5% | |
9.7 | 7.0 | |
7 days ago | about 1 month ago | |
Scala | Nim | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pekko
-
Is akka still worth learning to be employable?
Pekko is open source, has the same API. So there's no problem there.
- Migrate the classic transport of pekko to Netty 4 without CVEs
-
6 Common Misconceptions Around Akka-HTTP / Pekko-HTTP
Understandable considering the size of Pekko and how much time is passed, I would recommend asking any questions/concerns on either the Pekko mailing list https://lists.apache.org/[email protected] or on Github discussions https://github.com/apache/incubator-pekko/discussions.
-
Reconnecting with Scala. What's new?
Another big reason behind the "struggle" is we have done further improvements. For example the first release of Pekko will support all Scala versions from 2.12 up to 3.3.0 LTS (which was just released a couple of days ago). This also includes Pekko's modules which means we had to either add back in Scala 2.12 support or Scala 3 support. Yet another example would be https://github.com/apache/incubator-pekko/pull/281 which allowed us to drop scala-java8-compat dependency for Scala 2.13 or higher. So while these improvements aren't technically necessary, they have a large impact on Pekko going forward, i.e. the scala-java8-compat change means that we can drop Scala 2.12 at any point in time without breaking users.
-
Scala opensource projects
Apache Pekko is the open source fork of Akka. I know they can use more hands right now - https://github.com/apache/incubator-pekko/issues
-
What is the current status of Akka in your organisation?
There is an option missing: Considering switching to pekko when it's ready: https://github.com/apache/incubator-pekko
-
Stop Building on Corporate-Controlled Languages
- In 2022, Lightbend changed the Akka licence, made it proprietary and very expensive at large scale
Software that starts out as more "pure", non-corporate open-source can still turn the tables on you and charge large licensing fees later. But at least if it's open source from the start, it can be forked, e.g. for Akka, there's this Apache fork that was started after Akka changed its licence: https://github.com/apache/incubator-pekko . This is the key open source protection, and it's true for both corporate and non-corporate projects.
questionable
-
Nim v2.0 Released
> You can also not really have productive and well-fitting errors-as-values in a language that emphasizes UFCS
Eh, https://github.com/arnetheduck/nim-results and associated syntax from https://github.com/codex-storage/questionable would beg to disagree. Nim's stdlib does not have productive and well-fitting errors because it suffers from inertia and started far before the robust wonders of recoverable error handling via errors-as-types entered the mainstream with Rust (IMO: and refined with Swift). Option/Result types are fantastic and I do so wish the standard library used them: but it's nothing a (very large) wrapper couldn't provide, I suppose.
I do strongly think that other languages are greatly missing out on UFCS and I miss it dearly whenever I go to write Python or anything else. I'm not quite sure how you think UFCS would make it impossible to have good error handling? Rust also has (limited, unfortunately) UFCS and syntax around error handling does not suffer because of it. If by errors-as-values you mean Go-style error handling, I quite despise it - I think any benefits of the approach are far offset by the verbosity, quite similarly to Java's checked exceptions.
-
Stop Building on Corporate-Controlled Languages
If exceptions aren’t your cup of tea, look into using stew/results and questionable instead:
https://github.com/status-im/nim-stew/blob/master/stew/resul...
https://github.com/status-im/questionable#readme
Re: std/db_sqlite, your probably better off using sqlite3_abi:
https://github.com/arnetheduck/nim-sqlite3-abi#readme
What are some alternatives?
zio-akka-cluster - ZIO wrapper for Akka Cluster
nim-chronos - Chronos - An efficient library for asynchronous programming
ZIO - ZIO — A type-safe, composable library for async and concurrent programming in Scala
owlkettle - A declarative user interface framework based on GTK 4
Scala Native - Your favorite language gets closer to bare metal.
v - Write Nim only with 'v'
scala-cli - Scala CLI is a command-line tool to interact with the Scala language. It lets you compile, run, test, and package your Scala code (and more!)
sokol-rust - Rust bindings for the sokol headers (https://github.com/floooh/sokol)
Play - The Community Maintained High Velocity Web Framework For Java and Scala.
sokol-zig - Zig bindings for the sokol headers (https://github.com/floooh/sokol)
nim-sqlite3-abi - SQLite3 wrapper
nlvm - LLVM-based compiler for the Nim language