michaelbull
Joined 10 years ago
Joined 10 years ago
If this was true, why do Jetbrains themselves keep reinventing their own per-domain Result classes for their new code? For example, in their coroutines library they invented another Result type specifically for Channels[1] and isn't interoperable at all with their other Result type[2] that was also originally written to facilitate some of the coroutines code.
If Jetbrains' own internal library authors keep reaching for a Result type then I think we're better off following suit, because if they thought exceptions were superior in this example, they would have used them.
[1] https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-corout...
[2] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-result/
Please could you elaborate on what "looking thread safe" means to you? The only portion of the library that supports concurrency *is* thread safe - the unit tests[2] prove it and the use of concurrency primitives such as Kotlin's Mutex[3] are indicative of this.
I truly have no idea how you've judged the entirely of the library on whether it's "thread safe" when there is a single function (in an extension library, not the core one) that's related to concurrency and it is very clearly using concurrency primitives as intended.
With regards to "being cautious using it", you don't need to be. The maven central statistics suggest its being downloaded 300,000 times per month. If there was something wrong with it, it's likely somebody would have raised this already given how frequently the project has been adopted over the last seven years.
[1] https://github.com/michaelbull/kotlin-result/blob/master/kot...
[2] https://github.com/michaelbull/kotlin-result/blob/master/kot...
[3] https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-corout...
https://github.com/roman01la/webpack-closure-compiler
https://github.com/camelaissani/rollup-plugin-closure-compil...
Coming from Angular 1.x is a very natural progression (and TypeScript makes you wonder how you survived with ES5...). I briefly tried Vue and was not at all keen on shoving logic & presentation markup all in one file.
The only thing I've found troublesome is how spread the modules are. The router, the templating, etc is all separate from the framework - which is obviously good design but leaves you to piece together the bits you actually need yourself. Other than that the standard things like DI, Routing, Custom elements, are all implemented to an amazing standard by the Aurelia team.
Aurelia is a really great framework, I just hope it gets more traction as others have recently. My first experience with frontend frameworks was Angular 1.x, but transitioning to Angular 2 just didn't feel right. I've also tried projects in React & Vue, but neither seem as well-rounded and feature-rich as Aurelia.
You're right in your assumptions of Aurelia, Angular 2, Ember all being opinionated, however I think the "opinions" are often different in Aurelia's approach. They are putting a strong emphasis on adopting existing and emerging web standards (their custom element/attribute stuff is all following the web components standard), which I can see helping to fight against the fatigue that lots of people face with the 'flavour of the month' framework, as it'll no longer be what a team of developers thought was best at the time and will be the opinions of a standardisation team that has no vested interest in the framework itself.