<p>What are some factors that determine what features get built into the language itself and which ones get implemented in the standard library?</p>

<language-design><standard-library>
Language Feature vs Standard Library
CC BY-SA 4.0
2023-05-18T05:05:20.380Z
When you say features, do you mean things such as constants, functions, and classes?
FireTheLost
CC BY-SA 4.0
2023-05-18T12:24:37.733Z
I feel like this is mostly up to the language author's preferences.
Ginger
CC BY-SA 4.0
2023-05-18T15:24:53.650Z
I was looking at Rust's documentation and their Option is in the standard library whereas it's built into Kotlin directly.
CaseyB
CC BY-SA 4.0
2023-05-18T22:41:17.053Z
@CaseyB Kotlin does not have an option type
Seggan
CC BY-SA 4.0
2023-05-19T23:32:12.470Z
@Seggan, that's what I'm saying, the idea of an optional is built into the language whereas it's a type in the standard library with Rust.
CaseyB
<h1>C-Specific Information</h1>
<p>C was designed so that the built-in language features could be cleanly reflected by processor instructions. <code>+</code> becomes a simple <code>add</code> instruction, etc.</p>
<p>More complex functionality such as mathematical functions, that might not be available in a single (or otherwise trivial number) of instructions were delegated to standard libraries. This is why <code>fmod</code> exists in C instead of <code>%</code> operator for floats. Not all of the targeted CPUs at the time may have had such an instruction.</p>
<h2>Why</h2>
<p>C has a concept of hosted and freestanding implementations. Freestanding lacks much of the standard library, and is considerably easier for an implementer for an embedded system to implement. So features that would be universally trivial to implement are built-in to the language, and the rest is delegated to the standard library.</p>

CC BY-SA 4.0
2023-05-18T05:04:47.193Z
2023-05-18T05:04:47.193Z
CPlus
<p>The most common choice I've seen for toyish languages is putting everything that can be implemented in userland in the standard library, and everything else as a feature</p>
<p>The bigger a language becomes (and the more targets it has) the harder this becomes to do, both for performance and readability reason. Sure, you can add C FFI as a feature and then use the C standard library inside your fs functions, but that will eventually get annoying (not all targets have complete C standard libraries, some have quirks that have to be worked around, some have faster proprietary alternatives, ...). Of course you can't add a language feature for everything you want to be implemented natively.</p>
<p>I think the &quot;everything that can go in userland is in userland&quot; part is still generally followed by most languages, whether toy or not. A good standard library can serve as an example of what is &quot;good&quot; code for a language, both paradigmically and stylistically.</p>

CC BY-SA 4.0
2023-05-18T05:11:03.613Z
2023-05-18T05:11:03.613Z
RubenVerg
# Language Feature vs Standard Library
Posted by: username_0 on 2023-05-18
What are some factors that determine what features get built into the language itself and which ones get implemented in the standard library?
**Tags:** language-design standard-library
> **Comments:**
> **username_1**: When you say features, do you mean things such as constants, functions, and classes?  
> **username_2**: I feel like this is mostly up to the language author's preferences.  
> **username_0**: I was looking at Rust's documentation and their Option is in the standard library whereas it's built into Kotlin directly.  
> **username_3**: @CaseyB Kotlin does not have an option type  
> **username_0**: @Seggan, that's what I'm saying, the idea of an optional is built into the language whereas it's a type in the standard library with Rust.  
---
## 2 answers
### Answer by username_4 on 2023-05-18. Score: 5
# C-Specific Information

C was designed so that the built-in language features could be cleanly reflected by processor instructions. `+` becomes a simple `add` instruction, etc.

More complex functionality such as mathematical functions, that might not be available in a single (or otherwise trivial number) of instructions were delegated to standard libraries. This is why `fmod` exists in C instead of `%` operator for floats. Not all of the targeted CPUs at the time may have had such an instruction.

## Why

C has a concept of hosted and freestanding implementations. Freestanding lacks much of the standard library, and is considerably easier for an implementer for an embedded system to implement. So features that would be universally trivial to implement are built-in to the language, and the rest is delegated to the standard library.
---
### Answer by username_5 on 2023-05-18. Score: 5
The most common choice I've seen for toyish languages is putting everything that can be implemented in userland in the standard library, and everything else as a feature

The bigger a language becomes (and the more targets it has) the harder this becomes to do, both for performance and readability reason. Sure, you can add C FFI as a feature and then use the C standard library inside your fs functions, but that will eventually get annoying (not all targets have complete C standard libraries, some have quirks that have to be worked around, some have faster proprietary alternatives, ...). Of course you can't add a language feature for everything you want to be implemented natively.

I think the "everything that can go in userland is in userland" part is still generally followed by most languages, whether toy or not. A good standard library can serve as an example of what is "good" code for a language, both paradigmically and stylistically.
---
