Go

Go's garbage collector is unpredictable and unsuitable for latency-sensitive environments like high-frequency trading or real-time analytics. GOMEMLIMIT is described as unreliable, allowing requests 10x over the limit.

Python's accessibility flooded the market with junior developers, creating intense competition for entry-level roles. Companies migrate to Go or Kotlin for performance/type safety, and AI startups prefer Julia/Rust, leaving Python devs maintaining legacy models.

Go's goroutines lack compile-time safety guarantees, leading to orphaned routines, race conditions, and deadlocks. Unlike Rust, Go offers no memory safety at compile time. Additionally, goroutineID is not exposed, making debugging and logging difficult.

28% of developers want language features missing from Go that are available in other languages. Common requests include proper enums, union types, sum types, pattern matching, and nil pointer safety. Existing generics are criticized as half-baked.

Go's repetitive if err != nil pattern is seen as verbose boilerplate compared to modern error handling in Rust and TypeScript. Developers report fatigue and decreased productivity in large codebases, and 28% of survey respondents want language features for better error handling.

Go's built-in data structures (maps, slices, arrays) are not thread-safe despite the language's strong concurrency support. Developers must manually implement synchronization using goroutines, channels, or the sync package, creating inconsistency in how concurrency is handled.

Sending to a closed channel panics instead of returning an error or boolean. Channels also lack common blocking queue operations like peeking or fetching multiple items. Producers blocked on a closed channel panic, and improper usage easily leaks goroutines.

Go's go get and package structure don't support pinning dependencies to different versions, making reproducible builds and dependency management frustrating for projects with many dependencies. This is a critical gap for a language geared toward large-scale projects.

Setting up instrumentation in Go is painful and time-consuming, requiring 6-8 months of effort. Unlike Java or Python where OpenTelemetry works out-of-the-box, Go requires significant manual boilerplate and careful context propagation.

Microsoft is rewriting the TypeScript compiler in Go with breaking changes planned for TypeScript 7, plus new Node.js native TypeScript support that only strips types without type-checking. This creates ecosystem fragmentation where tools have different capabilities and developers must understand multiple execution paths.

When implementing observability in Go, developers generate massive volumes of data (trillions of requests) that must be filtered and managed. Telemetry costs and data quality issues remain persistent problems despite tuning efforts.

New team members spend days or weeks learning project-specific implementations of common patterns before becoming productive, significantly impacting project timelines and team productivity.

37% of developers familiar with SIMD have been impacted by Go's absence of native SIMD support. 17% report being limited in the performance they can achieve in their projects, and 15% had to use another language instead.

58% of teams report challenges identifying performance issues in running Go programs, and 57% struggle with identifying resource usage inefficiencies.

Despite being a hallmark of Go, channels are slow and throw away language niceties like defers and interface indirection when optimizing for performance. Developers must abandon many of Go's features to achieve high performance.

Go struct literals appear suitable for config parameters but provide no compiler enforcement for required fields. Omitting mandatory fields compiles without error, leading to silent bugs at runtime.

Error handling depends on matching error message strings, which are not compiler-enforced. When package authors change error messages, downstream error handling logic breaks silently with no compile-time protection.

Overusing goroutines leads to excessive context switching, performance degradation, and memory waste. 10,000 goroutines can consume 20+ MB of memory with overhead, and the Go scheduler incurs penalties causing throughput to halve.

Channels are frequently misused for synchronization tasks better handled by function returns or shared memory. 60% of Go applications experience performance degradation from deadlocks, and indefinite blocking on channels causes goroutine leaks.

33% of Go developers struggle to ensure their code follows idiomatic patterns and best practices. Developers switching between Go and other languages face cognitive load, and many request official guidance and tooling support to enforce idioms.

Go lacks default implementations for common interfaces and relies on runtime reflection to handle operations like printing structs or maps, which sidesteps the type system entirely. This creates ad hoc, edge-case-laden behavior.

Go has an extensive list of subtle gotchas and counterintuitive behaviors across data structures, concurrency primitives, JSON handling, and more (e.g., nil interfaces vs nil interface values, closed channel panics, unexpected range clause behavior). These are documented in community resources but create a steep learning curve.

Go's WebAssembly (WASM) support remains half-baked compared to Rust and TypeScript, which dominate in the WASM development arena.

Error wrapping up the call stack and garbage collection of intermediate objects is nearly as expensive as try-catch, yet requires manual coding. Stack traces provide redundant information most of the time and lack a mechanism to toggle them.

Go lacks a standard library for GUI development. Third-party solutions exist but lack proper integration and comprehensive documentation, hindering cross-platform graphical application development.

Go doesn't allow adding methods to types from different or standard library packages. Instead, developers must create wrapper types, resulting in additional boilerplate and code that is harder to understand and maintain.

Half of Go developers fail to write adequate unit tests, despite Go's testing package being available. This widespread neglect of testing reduces code reliability and maintainability.

26% of developers report difficulty finding trustworthy Go modules. Developers lack reliable quality signals, maintenance indicators, and usage context to evaluate third-party modules.

Only 25% of survey respondents found the Go language contribution process easy to understand, and only 28% felt the project leadership responded well to questions. This creates barriers for developers wanting to contribute or influence the language direction.

Most documented paths for getting started with AI-powered applications are Python-centric, causing organizations to start in Python before migrating to Go. This creates friction in the adoption of Go for production AI workloads.

Go's reliance on symbol case for visibility (uppercase=public, lowercase=private) creates unintended variable shadowing. Developers cannot use natural names like 'user' for a user variable because it shadows the user type, forcing awkward one-letter naming conventions.

Go enforces many strict formatting and syntax rules that developers find overly rigid, including constraints on brace placement, variable declarations, and operator usage. These rules limit expressiveness and feel unnecessarily restrictive.

While most Go developers use AI tools for learning and coding tasks, satisfaction is middling. 53% report that tools create non-functional code, and 30% complain that even working code is poor quality. AI struggles with complex features.

Developers express concerns about potential vendor lock-in and lack of control given that Go is primarily controlled by Google. This is seen as problematic compared to languages with large, independent open-source communities.

Go's design philosophy emphasizes simplicity but limits metaprogramming features. Reflection is available but not as powerful or easy to use as in Python or Ruby, restricting dynamic code generation and runtime behavior manipulation.

The go line in go.mod includes patch-level versioning instead of just language version, forcing cascading updates when libraries bump the version without meaningful feature usage or benefit.

New Go developers struggle with understanding type assertions and conversions, leading to unexpected behavior especially with maps and slices. Poor type system documentation exacerbates the problem.

Go produces unexpectedly large binaries, which is a concern for deployment and distribution.

Despite Go modules being the recommended approach, 37% of developers still use vendoring which causes compatibility and portability issues. Lack of consistent version control with modules persists.

Go lacks powerful IDE support and modern tooling compared to other ecosystems, with documentation and language features lagging behind contemporary standards.

Developers cannot easily use a forked version of a dependency while waiting for an upstream bug fix, creating friction in the development workflow.

Testing dependencies appear in go.mod alongside production dependencies, creating unwanted coupling and making dependency management harder to reason about.

15-25% of developers frequently need to review documentation for common Go CLI subcommands like `build` and `run`. The underlying issue is navigating and parsing the help system itself rather than just remembering flags.

The Go playground and go doc tools don't include basic syntax highlighting due to an early Go team member's design preference against colors, resulting in poor developer experience.