Pains
2403 pains collected
TensorFlow training loop creation is tricky and not beginner-friendly
5Creating training loops in TensorFlow is considered unintuitive and difficult to figure out, reducing developer productivity and increasing the learning curve especially for those coming from simpler frameworks.
Asynchronous Programming Confusion for Beginners
5Despite improvements with async/await syntax, JavaScript's asynchronous programming model remains confusing for developers, especially beginners trying to understand callback ordering, promise chains, and error handling in complex scenarios.
Multiple incompatible standard implementations of basic data structures
5C++ lacks standard types for basic data structures like strings, arrays, and lists, or has multiple competing standards and non-standard implementations. Each interface works with different string/container variants, making code reuse difficult and forcing runtime type conversions, reducing performance and maintainability.
macOS universal binary codesigning issues and inability to build from architecture subcomponents
5Tauri cannot properly create macOS universal binaries from separate arm64 and x64 builds, and performs redundant codesigning on macOS builds. While not hard blockers, these issues are annoying enough to delay migration decisions.
AWS feature rollout is unpredictable and not customer-driven
5AWS does not communicate when services will be ready or whether specific requirements will be supported. Features evolve unpredictably, and if AWS doesn't add needed functionality within required timeframes, developers must compose workaround services.
Pointer Tagging Portability and Verification
5Pointer tagging—packing additional data into unused pointer bits—lacks universal portability across systems. Developers struggle to verify whether certain pointer bits are actually unused on a given target system, limiting practical application despite hardware design opportunities.
STL Over-Inlining and Allocator Ignorance
5STL implementations excessively inline code and ignore custom allocator type members, limiting optimization opportunities and making memory management customization ineffective in performance-critical scenarios.
Plugin ecosystem maturity affects feature availability
5Tauri's long-term success depends on the growth of official and community plugin repositories; insufficient plugin availability limits access to native functionality developers need.
Memory leaks from unclosed database connections
5Developers frequently forget to properly close SQLite database connections, leading to memory leaks and performance degradation over time. This requires developers to implement proper connection lifecycle management patterns.
Heavy resource usage despite size advantages over Electron
5Tauri apps consume significantly more resources than native applications (10x worse in some metrics), still requiring manual closure to avoid system sluggishness, limiting its lightweight promise.
Platform inconsistency compared to Tauri's system WebView approach
5While Electron provides true cross-platform consistency by bundling Chromium, alternatives like Tauri rely on system WebViews that vary significantly across OS versions (particularly problematic on Linux), creating debugging challenges. Tauri's approach yields much smaller binaries (10-20MB vs 50-90MB).
Slow project loading and navigation in large codebases
5Opening files and loading large C++ projects is slow, and navigation between header and source files is cumbersome, causing delays during development.
Inconsistent JavaScript Rendering Across Browsers
5Different browsers interpret JavaScript code slightly differently, causing inconsistencies in rendering and functionality across platforms, requiring additional testing and workarounds.
Unclear separation of concerns between Builder/App/Window/Runtime entities
5The responsibilities and relationships between Builder, App, Window, and Runtime objects, along with their proxy and handler types, lack clarity in the codebase, making it difficult for developers to understand how to properly use the API.
C++ condition variables have spurious wake-ups and complex syntax
5The condition variable implementation in the standard library is plagued by spurious wake-ups and has unnecessarily complicated syntax compared to other languages.
Snap Package Performance and Overhead
5Snap packages are slower to launch, consume more disk space, and create additional mount points, contributing to system bloat. They represent a departure from the Unix philosophy of small, efficient programs.
Aggressive commercial upselling disrupts user experience
5Canonical aggressively promotes Ubuntu Pro subscriptions through MOTD messages, apt output, and website navigation, with ads appearing in the Apps menu. This commercial behavior alienates users and contradicts FLOSS principles.
Dependency Bloat and Resource Consumption
5Unnecessary or redundant dependencies lead to bloated codebases, increased resource consumption, and performance issues. Managing bloat requires regular audits and optimizations.
Difficult string and UTF-8 handling
5String manipulation in C++ is cumbersome and lacks convenience functions. UTF-8 support is only now emerging in the standard library after years of using workarounds.
Gossip protocol introduces higher failover latency than consensus algorithms
5Redis uses a gossip protocol and majority voting for failure detection instead of formal consensus algorithms like Raft or Paxos, reducing implementation complexity but increasing latency during failover operations.
System Bloat from Pre-installed Applications
5Ubuntu ships with many pre-installed applications and tools that create system bloat. What was once a minimal install is now heavy, leading to slower overall performance and loss of Ubuntu's identity.
Reduced User Choice and Control
5Ubuntu's design decisions sometimes force users down specific paths rather than empowering them. The shift toward a more controlled environment limits freedom and flexibility that Linux traditionally offered.
No standard multithreading patterns
5There is no standardized way to structure multithreaded code in C++, leaving developers to create bespoke solutions.
Framework perceived as overengineered for complexity added
5Many developers perceive Next.js as overengineered, adding unnecessary complexity without proportional benefits. The framework's architectural decisions and accumulated features create bloat that doesn't serve most use cases.