What we learned from 349 OCaml users across 50 countries:
OCaml's technical foundation is exceptional: 87% of survey participants are satisfied with the language, 74% find OCaml code highly maintainable, and OCaml 5 adoption reached 35% already in early 2023. However, three ecosystem gaps limit broader adoption:
These are coordination problems, not research problems. Small sustained contributions from library maintainers, educators, employers, and experienced developers have the potential to transform the ecosystem. We will follow up with specific actions and recommendations in the discussion of the survey results below.
The OCaml Users Survey 2023 received 349 responses from developers across 50 countries between February 10 and March 10, 2023, a 25% increase from the 280 responses in 2022. Survey participants represent diverse backgrounds: 64% have 3+ years of OCaml experience, 46% use OCaml professionally in industry, 30% in research, and 55% as hobbyists. The geographic reach spans from established OCaml strongholds (France: 30%) to growing communities worldwide, with responses from every continent.
This is the third iteration of the OCaml Users Survey, following surveys in 2020 (745 responses) and 2022 (280 responses). Survey participation varied significantly: the 2020 survey attracted 745 responses with high novelty factor, 2022 saw a sharp 62% decline to 280 responses (attributed to reluctance to use Google Forms, geopolitical factors, and drift of Reason users away from OCaml as ReScript diverged), and 2023 recovered 25% to 349 responses. The 2023 recovery suggests stable core community engagement. The ability to track trends across three years reveals both sustained strengths and persistent challenges, helping the community prioritize efforts for maximum impact.
About this report: This analysis is based on survey data collected in February-March 2023 but is being published in Spring of 2026. While some specifics reflect 2023 conditions (compiler versions, specific tool usage), the underlying patterns (documentation challenges, onboarding friction, and talent market dynamics) remain relevant based on ongoing community discussions. We intend to publish future survey reports more promptly.
OCaml's core strengths remain exceptional. 87% language satisfaction, 74% find code highly maintainable, and the community successfully adopted multicore support within one year of OCaml 5.0's release. The compiler release cycle is healthy, core application domains are stable, and satisfaction metrics have remained consistently high across three years of surveys. OCaml's technical foundation is solid.
We're held back not by the language itself, but by ecosystem gaps that discourage the next wave of adoption. Three persistent barriers emerged:
1. Documentation (25% ranked it top priority): Only 23% find libraries well-documented, down from 28% in 2022, while 41% actively disagree that documentation is adequate.
2. Onboarding friction (62% agree tooling confuses newcomers): The dune/opam relationship remains opaque to new users, error messages are cited as unhelpful, and "getting started" experiences create unnecessary barriers.
3. Talent market deadlock (50% cite hiring difficulty as adoption barrier): Companies can't find OCaml developers to hire, developers see few job opportunities, and 41% work as the only OCaml user at their workplace.
These are coordination problems requiring sustained community effort. While the data we base this hypothesis on is from 2023, ongoing discussions suggest that the underlying patterns persist. The "Three-Year Survey Trends" section below analyzes these patterns in historical context, while later sections discuss each barrier in detail with potential paths forward.
| Metric | 2020 | 2022 | 2023 | Trend |
|---|---|---|---|---|
| Language satisfaction | 85.7% | 86.4% | 86.8% | → Stable high |
| Code maintainability | 76.6% | 80.8% | 73.5% | ↑ then ↓ |
| Library stability | 68.8% | 74.8% | 68.6% | ↑ then ↓ |
| Feel welcome in community | 68.0% | 81.8% | 73.5% | ↑ then ↓ (but above 2020) |
While the rest of this report is looking at the challenges OCaml faces, it's important to also recognize significant achievements from 2020-2023:
Multicore Success: OCaml 5.0's December 2022 release delivered multicore support, a years-long effort culminating in a major technical milestone. By early 2023, 35% had already adopted OCaml 5.x, an extraordinarily fast uptake for a major version with breaking changes. This demonstrates the community's ability to execute complex migrations successfully when the value proposition is clear.
Build Tool Consolidation: Dune achieved 93% adoption by 2023 (up from ~80% in 2020, 91% in 2022), with all alternatives combined representing less than 10% of users. This unified tooling reduces cognitive load for newcomers and simplifies CI/CD workflows. Makefile usage declined from 42.6% (2022) to 38.6% (2023), suggesting makefiles increasingly complement dune rather than compete with it.
Package Management Standard: Opam public repository usage reached 89.3% in 2023 (up from ~80% in 2020, 88.4% in 2022), establishing it as the de facto standard for OCaml package management.
Compiler Currency: The community keeps pace with releases. 89.7% used OCaml 4.13 or newer in early 2023 (including 46.3% already on OCaml 5.x released December 2022), and 47.1% test new releases within one month. The primary friction is dependency compatibility (41.8%), not language changes or compiler bugs, while 35.4% report upgrades are "perfectly smooth."
Language Satisfaction: 87% language satisfaction across three consecutive surveys proves OCaml delivers on its core promise. Users who commit to OCaml genuinely love it; this foundation enables growth.
Welcoming Community: 74% feel welcome (2023) with only 3% disagreement, up from 68% in 2020. The 2022 peak of 81.8% shows the community has made real progress on inclusivity. Online forums remain helpful, and experienced users actively support newcomers.
Stable Libraries: 69% satisfied with library stability (2023) shows the ecosystem produces reliable code. This conservative culture, while sometimes slowing feature adoption, creates production-worthy software.
Testing and Benchmarking Culture: Testing adoption increased from 2022 to 2023: separate unit tests grew from 67.3% to 73.1%, while expect tests (40.4% to 40.5%) and property-based testing (24.1% to 24.8%) remained stable. Among the 58% who benchmark (2023), 55.2% use whole-program measurements, comparable to 2022's 82% of those who benchmarked. The ecosystem demonstrates strong engineering practices with quality-conscious testing culture.
These achievements demonstrate the community's capability for coordinated effort. The analysis and recommendations in the following sections apply this same collaborative energy to remaining gaps.
Primary usage contexts show stable patterns:
| Context | 2020 | 2022 | 2023 | Trend |
|---|---|---|---|---|
| Hobbyist | 56.7% ("at home") | 54.5% | 62.5% | → Stable majority |
| Industry work | 52.2% | 46.6% | 40.4% | ↓ Declining |
| Research | 26.7% | 30.5% | 29.8% | → Stable ~30% |
| Student | 10.2% ("at school") | 11.5% | 11.5% | → Stable ~11% |
The hobbyist segment remains OCaml's largest user base (62.5% in 2023), while professional industry usage among survey respondents has declined from 52.2% (2020) to 40.4% (2023). This trend correlates with the workplace isolation increase.
Application types remain focused on core strengths:
Top applications in 2023 (% of 349 respondents):
The 2022 data showed similar patterns (developer tooling 39.1%, web backend 36.2%, web frontend 29.0%), confirming OCaml's strength in language tooling, web development, and formal verification.
Academic strength persists:
| Domain | 2022 | 2023 | Trend |
|---|---|---|---|
| Academia/Research | 45.1% | 38.4% | ↓ Still dominant but declining |
| Web | 32.7% | 26.9% | ↓ Declining |
| Banking/finance | 14.0% | 14.0% | → Stable |
| Blockchain/crypto | N/A | 12.9% | New significant presence |
| Education | 14.8% | 13.2% | → Stable |
| Security | 12.1% | 13.2% | → Stable |
Academia remains the dominant domain (38.4% in 2023) but has declined from 45.1% (2022). The 2022 report noted: "OCaml seems still mainly used in an academic or R&D setting. As with the previous survey, the Web industry and financial industry are well represented." OCaml's academic strength provides stability but also highlights the challenge of expanding into mainstream industry adoption.
Cross-compilation gap narrows but persists:
| Platform | Development (2022) | Development (2023) | Deployment (2022) | Deployment (2023) | Gap (2023) |
|---|---|---|---|---|---|
| Linux | 83.4% | 84.0% | 91.3% | 92.0% | +8.0pp |
| macOS | 28.5% | 33.0% | 42.5% | 42.4% | +9.4pp |
| Windows | 9.4% | 8.0% | 30.5% | 21.5% | +13.5pp |
The Windows deployment gap, even though it improved from 21.1pp (2022) to 13.5pp (2023), remains the most pronounced: only 8% develop on Windows, yet 21.5% target it. This persistent cross-compilation challenge might explain the surge in cross-platform support priority (+10pp from 2022 to 2023, +14pp from 2020 to 2023).
Documentation satisfaction has remained stubbornly low across all three surveys (23-28% satisfied), while active dissatisfaction has grown dramatically:
The widening gap between satisfaction and dissatisfaction tells the story:
Between 2022 and 2023, something changed. Dissatisfaction jumped 11 percentage points in a single year, the largest single-year movement of any metric across all three surveys. This suggests the community has reached a breaking point where documentation inadequacy has shifted from "annoying limitation" to "critical barrier."
Tooling confusion has been essentially frozen at ~62% for three consecutive surveys:
During this period, significant tooling improvements were made: dune matured and became dominant (91% in 2022, 93% in 2023), OCaml Platform LSP improved, and new learning resources were created. Yet the perception of the newcomer experience has not improved.
This plateau reveals an important insight: tooling improvements alone don't solve onboarding problems. The dune/opam relationship, error messages, project setup, and getting-started documentation need coordinated attention. Considering the more recent changes to dune between March 2023 and today, we are curious to see if/how these numbers change with the next OCaml Users Survey.
Workplace isolation has increased steadily and dramatically across all three surveys:
This is one of the most concerning trends in the data. Nearly 41% of OCaml developers work in isolation, lacking local mentorship, unable to justify OCaml for new projects, and facing career risk from non-transferable skills. This pattern suggests OCaml is becoming more concentrated in specific organizations while simultaneously spreading to more isolated practitioners elsewhere.
Meanwhile, the opposite end of the spectrum has remained stable: those in OCaml-centric environments (>50% projects use OCaml) were 35.3% in 2022 and similar in 2023. This reinforces the "all or nothing" pattern identified in the 2022 report: OCaml appears to be an all or nothing solution.
The hiring challenge has remained stubbornly persistent across all three surveys:
The 2022 report captured the dynamic well: "In an industrial setting, the lack of OCaml developers is a clear pain point in starting a new project with OCaml. But more generally (whether in an industrial or in open source projects) respondents seem to indicate that they would not choose OCaml due to the lack of critical libraries. These proportions have not changed much since the last survey (50.4% for hiring OCaml developers and 51.1% for the lack of libraries)."
This creates a chicken-and-egg cycle: companies hesitate to adopt OCaml due to hiring concerns, few OCaml jobs get posted, developers avoid specializing in OCaml, and the small developer pool reinforces companies' hesitation. Breaking this cycle requires coordination: creating supply and demand simultaneously through educational partnerships, job visibility, training programs, and talent pipeline development.
| OCSF Priority | 2020 | 2022 | 2023 | Trend |
|---|---|---|---|---|
| Library/ecosystem support | 75.6% | 76.8% | 74.9% | → Stable high ~75% |
| Compiler/core tools support | 72.1% | 65.8% | 72.5% | ↓ then ↑ back to 2020 |
| Industry promotion | 40.4% | 46.3% | 46.8% | ↑ Sustained increase |
| Student courses/education | 32.6% | 39.7% | 31.6% | ↑ then ↓ back to 2020 |
| Animate community | 32.1% | 28.7% | 29.8% | ↓ then → Stable ~29% |
| Cross-platform support | 22.9% | 26.8% | 26.3% | ↑ then → Stable ~26% |
| Community diversity | 22.9%* | 21.3% | 19.3% | ↓ Declining slightly |
| Professional training | 19.4% | 19.5% | 18.1% | → Stable low ~19% |
The three-year survey trends reveal:
The survey reveals clear opportunities. Companies using OCaml can amplify their impact by funding initiatives, allocating engineering time to improve shared dependencies, publishing case studies that inspire others, and building OCaml teams. Individual contributors can make a difference through documentation improvements, mentoring newcomers, or creating tutorials.
Every contribution strengthens the whole: Sponsored maintainers ship better libraries. Published case studies help isolated developers find peers. Engineering time invested in documentation reduces onboarding friction. Teams built around OCaml create the collaboration that 40.5% of solo practitioners seek.
Join the conversation on discuss.ocaml.org. Share your perspective. Small, sustained actions build the thriving ecosystem we all want to see.
The gap between recent users (18% with <1 year from Q1) and self-identified beginners (22%) suggests either rapid confidence building or survivorship bias, as those who struggle may leave before taking surveys. The substantial advanced/expert cohort (46%) provides mentorship capacity, though this concentration of expertise may inadvertently create barriers for newcomers navigating an ecosystem designed by and for experts.
The 62% hobbyist engagement significantly exceeds typical language surveys (20-40% hobby use), revealing OCaml's appeal extends beyond workplace requirements. Many users engage across multiple contexts (the percentages sum to >100%), with particular overlap between hobbyist and professional use. Despite strong academic roots, teaching represents only 3% of usage, suggesting OCaml's academic presence concentrates in specific institutions rather than broad curriculum adoption.
The bimodal "all or nothing" pattern (34% in OCaml-heavy workplaces versus 41% as sole users) reveals OCaml's adoption challenge. Unlike gradual-adoption languages (Python, TypeScript), OCaml rarely expands from pilot projects (only 18% report partial adoption). This mirrors specialized tools like Erlang that require team-wide commitment. The pattern has persisted unchanged since 2022, suggesting structural rather than temporary barriers.
The 34% uncertainty about workplace trends reveals many OCaml developers operate in organizational blind spots, using the language in isolation without visibility into broader adoption patterns. Combined with the 41% working as sole OCaml users (Q4), this suggests a fragmented professional landscape where individual champions drive usage rather than organizational strategy.
The 58% self-taught majority reveals OCaml attracts intrinsically motivated developers who seek it out for technical merits rather than external requirements. With only 6% learning at work (unusually low for programming languages), OCaml's growth depends on individual initiative rather than organizational training programs. This creates both a highly motivated user base and a limited growth pipeline.
French institutions dominate responses, with ENS and grandes écoles appearing repeatedly. This concentration reflects OCaml's INRIA origins and integration into French CS curricula as the standard functional programming teaching language. International mentions (Cornell, Cambridge) appear sporadically, suggesting adoption depends on individual professors rather than systematic curriculum integration. The geographic concentration creates both stability (guaranteed pipeline) and vulnerability (dependent on French educational policies).
The polyglot profile reveals OCaml users work across abstraction levels, from systems (C at 59%, Rust at 27%) to high-level (Python 54%, JavaScript 44%). The 17% using formal verification tools (Coq, Lean, Agda, Idris) far exceeds general developer populations, indicating OCaml attracts those working on correctness-critical systems. This diverse language portfolio suggests OCaml often serves specialized roles within polyglot architectures.
Developer tooling and programming language implementations (both 39%) dominate use cases, reflecting OCaml's comparative advantage in building language infrastructure. Web development's strong showing (36% backend, 26% frontend) proves OCaml has expanded beyond traditional niches. However, minimal adoption in ML/AI (8%) reveals ecosystem gaps where OCaml cannot compete with specialized platforms.
While academia leads at 44%, commercial sectors show substantial presence: web (31%), finance (16%), blockchain (15%). The blockchain adoption notably includes Tezos, demonstrating OCaml's value for high-assurance systems. The overlap between academic and commercial use suggests many respondents straddle both worlds, using OCaml for research that transitions to production systems.
Academic institutions remain OCaml's primary discovery channel (39%), creating dependency on university curriculum decisions. Online discovery (29% combined) provides an alternative growth path but remains secondary to formal education.
This question generated the richest feedback (223 responses). Key pain points cluster around the dune/opam relationship confusion, uninformative error messages (especially versus Rust), and lack of practical examples. The absence of automatic derivation for basic operations (printing, equality) particularly frustrates developers from modern functional languages. These specific, actionable complaints provide a roadmap for ecosystem improvements.
One-third of respondents were unaware of the OCSF, suggesting room for improved visibility. Among survey-takers (likely more engaged than average users), this awareness gap may underrepresent the broader community's disconnection from Foundation activities.
Ecosystem and tooling support dominated priorities (75%), significantly outweighing industrial promotion (47%) or education (32%). This reflects a "fix the product before promoting it" mentality. One telling quote: "I've tried several times over the past couple decades to get into [OCaml], but each time I bounce off. It's not the language that's hard, it's the tools, libraries, and documentation."
While discuss.ocaml.org achieved primary platform status (61%), the 39% not using it indicates continued fragmentation. GitHub's role extends beyond code hosting (52% use it for interaction), while traditional channels like Caml-list persist (20%), showing generational diversity in communication preferences. No single platform captures the entire community.
Best practices content demand (58%) dramatically exceeds beginner fundamentals (13%), reflecting the experienced user base struggling with ecosystem navigation rather than language basics. The desire for library walkthroughs (33%), debugging how-tos (32%), and tooling choices (32%) reinforces that users need ecosystem guidance, not syntax tutorials.
The contribution pattern (57% working on 1-3 projects) suggests focused engagement rather than shallow involvement. The 19% non-contributors likely include evaluators and students. The small highly-active cohort (5% with 11+ projects) represents the ecosystem's maintenance backbone, raising sustainability concerns about depending on few individuals.
Project sizes cluster at small scale (65% with ≤5 contributors), reflecting both OCaml's niche status and the talent pool constraints identified in Q53. Large projects (>50 contributors) remain rare at 8%, suggesting OCaml rarely gets chosen for massive collaborative efforts, except notable examples like Tezos and the compiler itself.
The Windows development gap (only 8% vs 84% Linux) creates a barrier for enterprise adoption where Windows dominates developer desktops. This disparity exceeds even typical open-source projects and directly contributes to the cross-platform concerns raised in Q14. Mac OS (33%) serves as a Unix-compatible compromise for developers needing desktop productivity.
The deployment reality (Windows targeted by 22% but developed on by only 8%) reveals cross-compilation burden. Mobile platforms see negligible targeting (3% combined), confirming OCaml's absence from mobile development. The 94% Linux deployment reflects server-side focus but also limits OCaml to Linux-centric organizations.
Vanilla OCaml's dominance (95%) demonstrates successful avoidance of implementation fragmentation that plagues some languages. js_of_ocaml (30%) enables web deployment without fragmenting the core language. Reason's modest adoption (6%) suggests alternative syntax experiments haven't displaced traditional OCaml. Low fork rates (6% total) indicate upstream development meets most needs.
The 46% already on OCaml 5.x within months of release demonstrates successful multicore adoption, a major technical milestone. The 4.14 holdouts (39%) likely reflect production systems' conservative upgrade cycles. Minimal legacy version usage (≤4.13 at 11%) shows the community successfully migrates forward, avoiding version fragmentation.
The 4.14 baseline (22%) emerging as the de facto minimum reflects a community balance between stability and progress. Those supporting only latest releases (13%) are likely application developers, while 4.08 support (10%) accommodates long-term support system users. This distribution helps library maintainers prioritize compatibility efforts.
opam's dominance (88%) represents successful standardization comparable to Cargo in Rust. Alternative methods persist for specific needs: corporate environments (14% private repos), reproducible builds (10% Nix), and system integration (14% distribution packages).
The split between early adopters (25% test within a week) and conservatives (39% wait 6+ months) creates a healthy ecosystem where issues surface quickly but production systems maintain stability. The 70% testing within one release cycle indicates most users keep reasonably current, avoiding accumulated breaking changes.
Dependency incompatibility dominates upgrade friction (42%), revealing coordination challenges in the ecosystem. Yet 35% report "perfectly smooth" upgrades, suggesting problems concentrate in specific dependency trees rather than systemic issues. The compiler-internal API users (10%) represent advanced tool builders whose needs may conflict with stability goals.
The 46% satisfaction with the six-month cadence validates the current schedule. More interesting: 50% are either unaware or indifferent to the release cycle, indicating a substantial user segment disconnected from compiler development. They use stable versions without tracking releases. Only 4% find the pace problematic.
Dune's 93% adoption represents remarkable consolidation since its 2017 introduction. The persistent makefile usage (39%) suggests integration needs with non-OCaml components that dune doesn't fully address. One respondent's "dune for convenience but this tool is awful" highlights that monopoly doesn't equal satisfaction.
PPX dominance (68% using, 20% creating) confirms successful migration from camlp4/camlp5 (now 5%). The 25% using no preprocessors reveals a substantial "pure OCaml" cohort, either by preference or because their domains don't require metaprogramming. Active custom PPX development indicates healthy extensibility.
The three-way editor tie (VSCode 39%, Vim 39%, Emacs 36%) reflects generational and philosophical diversity, as modern IDE users coexist with traditional Unix editor adherents. Multiple editor usage (totals exceed 100%) suggests context-dependent choices. Low IntelliJ adoption (5%) indicates the OCaml plugin hasn't achieved parity with mainstream editor support.
GitHub's dominance (84%) mirrors industry trends. The 31% using self-hosted solutions (GitLab self-managed + other forges) indicates significant enterprise or privacy-conscious usage requiring infrastructure control.
High testing adoption (84% use tools) reflects quality-conscious culture. Traditional unit tests dominate (62%) but expect-tests (34%) show dune's cram-style testing gaining traction. Property-based testing (21%) exceeds mainstream language adoption, reflecting functional programming's formal specification affinity. Low fuzzing use (6%) suggests untapped potential.
The 42% not benchmarking likely includes domains where performance isn't critical. Among those who do, simple timing tools (55%) outweigh sophisticated microbenchmarking (23%), suggesting optimization focuses on algorithmic improvements over low-level tuning. Custom tooling proliferation (39%) indicates unmet needs in performance measurement.
Deployment method diversity reflects different audience targets: opam for OCaml users (39%), static binaries for end-users without OCaml (38%), Docker for cloud deployment (31%). Source distribution remains surprisingly high (39% combined), indicating trust in users' build capabilities. Low system packaging (8%) limits mainstream Linux distribution inclusion.
Self-hosted infrastructure preference (54%) reflects the community's technical sophistication and cost-consciousness. AWS's modest showing (25%) given market dominance suggests OCaml deployments skew small-scale where cloud premiums are hard to justify. Minimal Azure (3%) aligns with weak Windows ecosystem ties.
The 74% feeling welcome with only 3% disagreement indicates genuinely inclusive community culture. The 16% neutral may represent passive inclusion: not unwelcome but not actively welcomed either. The 8% "don't know" likely includes lurkers consuming content without engaging, unable to assess community tone from passive consumption.
The 87% language satisfaction dramatically exceeds typical programming language scores (60-75% in broader surveys) and represents OCaml's strongest metric. With only 3% dissatisfied, those who persist with OCaml genuinely find it meets their needs. This high satisfaction provides a foundation but shouldn't mask the ecosystem challenges revealed elsewhere.
Tooling satisfaction (65%) significantly lags language satisfaction (87%), identifying tooling as a relative weakness. The 15% dissatisfaction likely concentrates among Windows users, debugger seekers, and those needing IDE features. The 19% neutral may have adapted to limitations but wouldn't describe workflows as "comfortable."
The 62% consensus that tooling confuses newcomers, despite 65% of experienced users finding it comfortable (Q38), reveals a steep but surmountable learning curve. With only 8% disagreeing, even advocates acknowledge the onboarding problem. This validates the documentation and tutorial demands seen throughout the survey.
Half of participants (179) provided feedback, with unified tooling (merging dune/opam for Cargo-like experience) as the dominant theme. Documentation, Windows support, debugging capabilities, and simpler project setup round out the wish list. These specific, repeated requests provide clear direction for ecosystem improvements.
Package repository satisfaction (68%) aligns with general tooling satisfaction, confirming opam's core infrastructure works adequately. The 9% dissatisfaction is remarkably low for package management, an historically problematic domain. The 18% neutral suggests functional but unexceptional experience.
The 79 responses (23% participation) focus on performance (slow updates, compilation time) and discoverability (finding packages, assessing quality). A few responses raise security concerns (package signing, vulnerability tracking), suggesting growing production use where these matter.
Library availability shows the weakest satisfaction (55%) among ecosystem metrics, falling below tooling (65%) and repositories (68%). The 15% dissatisfaction represents users actively blocked by missing libraries. Combined with Q53 where 48% cite missing libraries as adoption barriers, this confirms library gaps as a critical growth constraint.
The 72 responses identify specific gaps: GUI frameworks, cloud SDKs (AWS, Azure), modern web frameworks, and data science tools. Notably, many complaints focus on documentation and maintenance uncertainty rather than absolute absence. Libraries exist but aren't discoverable or trustworthy. The repeated "blessed library" requests suggest decision paralysis from unclear quality signals.
Documentation quality shows the worst metrics in the entire survey: only 23% satisfied versus 37% dissatisfied. This represents a clear community crisis and the most actionable improvement area. The dissatisfaction exceeds satisfaction by 14 percentage points, unique among survey metrics. The large neutral cohort (34%) may have adapted to reading source code as documentation.
Library stability satisfaction (69%) provides a bright spot: existing libraries are reliable even if poorly documented or insufficient in number. The 5% dissatisfaction is remarkably low, suggesting OCaml's conservative culture produces dependable code. This stable foundation could support growth if documentation and discovery improve.
Less than half (48%) feel confident about best practices, explaining why this topped content requests (55% in Q16). The 21% acknowledging ignorance shows healthy self-awareness. The large neutral group (27%) likely includes developers unsure whether their patterns align with community norms, a solvable problem through documentation.
Maintainability scores (74% agreement) rank among OCaml's strongest selling points, second only to language satisfaction. This validates OCaml's core value proposition: type safety and functional paradigms produce maintainable code. The 4% disagreement is negligible, confirming this as a genuine strength rather than community bias.
The stark asymmetry (37% find jobs hard to locate versus 9% finding them easy) quantifies the employment challenge, though 40% selected "I don't know," likely reflecting those not actively job searching. Combined with Q53's hiring difficulties, this confirms the talent market deadlock.
The hiring manager perspective mirrors the candidate side: only 7% find it easy to hire qualified OCaml candidates, while 20% report difficulty. The dominant response is "I don't know" (62%), reflecting that most respondents are not in hiring positions. Among those with hiring experience, the difficulty outweighs ease by nearly 3:1, reinforcing the talent market deadlock seen in Q49.
An effect system (57%) tops the wishlist, followed closely by builtin deriving (49%) and typeclasses/implicits (44%). These three features share a common theme: reducing boilerplate while preserving type safety. The gap to the next tier is significant, with a more powerful module system (19%) and namespaces (17%) drawing far less demand. Only 11% selected "I don't know," suggesting most respondents have clear opinions on language evolution.
Documentation for user libraries dominates improvement priorities (25%), significantly exceeding build tools (15%) or package management (13%). This aligns with Q45's dissatisfaction metrics. The compiler (12%), core language documentation (11%), and communication to outsiders (11%) round out the top priorities, reinforcing the community's focus on documentation and outreach.
Hiring difficulty (50%) and missing libraries (48%) are the top two adoption barriers, creating interlocking constraints. Companies can't adopt without developers, developers won't specialize without jobs, and neither group invests in libraries for uncertain futures. Lack of developer tools (33%) and learning curve (28%) compound these primary barriers. Environment constraints (20%) and performance (5%) are cited far less, confirming problems lie in ecosystem rather than core language.
The 75 free-text responses cover a wide range of topics. Recurring themes include appreciation for OCaml's type system and expressiveness, frustration with tooling and documentation gaps, and calls for better marketing and community outreach. Several responses highlight the tension between OCaml's technical strengths and its ecosystem challenges.
Geographic concentration reveals both strength and vulnerability. France's 31% share provides a stable base but creates dependence on French institutions. The US (16%) and UK (8%) follow. The 50-country reach proves global interest exists despite concentration.
Two-thirds (67%) do not consider themselves part of an underrepresented group. Among those who do, LGBQ+ identity is most reported (9%), followed by age-related underrepresentation (7%) and racial/ethnic minority status (7%). Women or those perceived as women represent 5% of respondents, and 3% identify as trans. The low representation of women and racial minorities compared to the broader tech industry suggests the OCaml community faces significant diversity challenges.
Among those who belong to an underrepresented group, the majority (86%) say it never makes participation difficult. However, 14% report that it sometimes does, and 2% say it often does. The 60% selecting "N/A" are those who do not identify as part of an underrepresented group. While the absolute numbers are small (16 reporting any difficulty), these responses deserve attention to ensure the community remains welcoming to all.
This section contains all consolidated answers and text responses referenced in the main report.
Showing 2 variants consolidated into this answer (104 total responses)
Showing 9 variants consolidated into this answer (10 total responses)
Showing 6 variants consolidated into this answer (6 total responses)
Showing 10 variants consolidated into this answer (11 total responses)
Showing all 84 text responses
Showing 2 variants consolidated into this answer (57 total responses)
Showing 24 variants consolidated into this answer (25 total responses)
Showing 12 variants consolidated into this answer (12 total responses)
Showing 8 variants consolidated into this answer (8 total responses)
Showing 4 variants consolidated into this answer (6 total responses)
Showing 3 variants consolidated into this answer (4 total responses)
Showing 2 variants consolidated into this answer (3 total responses)
Showing 2 variants consolidated into this answer (2 total responses)
Showing 1 variant consolidated into this answer (1 total responses)
Showing 30 variants consolidated into this answer (27 total responses)
Showing 7 variants consolidated into this answer (9 total responses)
Showing 3 variants consolidated into this answer (3 total responses)
Showing all 219 text responses
Showing 13 variants consolidated into this answer (13 total responses)
Showing 6 variants consolidated into this answer (10 total responses)
Showing 9 variants consolidated into this answer (9 total responses)
Showing 2 variants consolidated into this answer (7 total responses)
Showing 4 variants consolidated into this answer (4 total responses)
Showing 14 variants consolidated into this answer (14 total responses)
Showing 6 variants consolidated into this answer (6 total responses)
Showing 10 variants consolidated into this answer (16 total responses)
Showing 4 variants consolidated into this answer (5 total responses)
Showing 5 variants consolidated into this answer (5 total responses)
Showing 4 variants consolidated into this answer (4 total responses)
Showing 3 variants consolidated into this answer (3 total responses)
Showing 8 variants consolidated into this answer (8 total responses)
Showing 29 variants consolidated into this answer (29 total responses)
Showing 11 variants consolidated into this answer (11 total responses)
Showing 10 variants consolidated into this answer (10 total responses)
Showing 3 variants consolidated into this answer (7 total responses)
Showing 7 variants consolidated into this answer (7 total responses)
Showing 22 variants consolidated into this answer (22 total responses)
Showing 22 variants consolidated into this answer (24 total responses)
Showing 21 variants consolidated into this answer (21 total responses)
Showing 18 variants consolidated into this answer (21 total responses)
Showing all 179 text responses
Showing all 78 text responses
Showing all 71 text responses
Showing all 75 text responses
Showing all 50 text responses
Showing 15 variants consolidated into this answer (15 total responses)
OCaml retains users exceptionally well: 64% have 3+ years experience, with 30% exceeding a decade. The small beginner cohort (18%) compared to veterans suggests OCaml attracts developers who commit long-term rather than experiment briefly. This experience distribution has remained remarkably stable across survey years, indicating consistent appeal to developers seeking production reliability over trend-driven adoption.