You need a lot of hubris to design your own programming language. As a result, new languages are often engineered (or "over-engineered") for that glorious future where millions of programmers spend their lives working with the language, and a small army is maintaining the compiler and related tools. But how would you design a language that assumes this bountiful future will never arrive? A language that, even in the best of circumstances, will always be obscure and secondary? Futhark is a programming language designed for a very specific domain: high-level, deterministic, data-parallel number crunching. It explicitly disavows general-purpose use, and it is absolutely not possible to write full applications in it. Thus, even if Futhark somehow managed to become the largest conceivable success and completely dominate its domain, that would not translate into very many programmers. And even then, it would at best be a secondary or third language for most of its users. In this talk I will talk about how such a perspective has affected the design of the Futhark language and its tools. To a first approximation, this is just the "principle of least surprise" applied to every part of the language and ecosystem. As a niche language, Futhark's novelty budget is quite limited, and its users will not have the inclination to learn about syntactical subtleties, elaborate package managers or build systems. At the same time, it's trying to innovate in a challenging domain, so some things definitely will have to be novel. Balancing these concerns has been interesting, and my experiences are perhaps even useful for designers of languages, tools, or systems in similar situations.