Frequently Asked Questions:
What is the use case for this language?
Websites, command line utilities and services. Bolin isn't meant to be embedded into other languages as a scripting language nor does it have a JIT. Bolin is designed to be suitable in places where C#, Java and Go are used. However Bolin is designed to be competitive with C execution speed. If you're not spending more than a few hours optimizing C code Bolin should be roughly the same speed or faster. See more optimal standard for an explanation and a run-able example.
How did you design readability?
There's a few decisions, some causing changes to the language. Most readability decisions had to do with reducing line noise.
- Not having var/let/auto in front of a variable declaration. This made us disallow member and global variables to be shadowed due to how easy it is to accidently create a local variable of the same name
- Instead of declaring two variables and writing an if (when a function returns a (result, error) tuple) you write resultVar = myfunc() error { /*error handle*/ }.
- You can use have multiple statements on a single line (with a semicolon). We don't force any whitespace
- Reduce if conditions. For example if you use on statements on for loops you don't need to write an if around the loop to check for null or empty, you don't need a variable+if to see if you broke out of a loop or ran it to completion. When assigning a variable instead of an if (or a ternary which has a condition) to check for null you can write nonNullVar = nullableVar ?? nonNullDefault
- Reducing clean up statements. There are destructors, Defer and errdefer is planned. There's automatic memory which not only cleans up the variable but chooses if it should be on the stack or heap. This allows better performance and gives us a reason to drop the new keyword reducing line noise. 'new' is often associated with heap memory which wouldn't be true if you want a 16 byte array
- Having defaults. For example function parameters are constant unless you specify otherwise. In a 'for to' loop you don't need to init the counter (which will be 0) nor say it increments by 1. for i to 10 {}
A few key places adding a keyword increase readability.
- The error keyword after a function call. It made it easy to see that function error is being handled since it immediately follows the call. The keyword is also at the top of a codeblock making it easy to notice that the block is executed only in an error state.
- Having 'mut' after a variable in a function call (maybeChange(a, b mut). If you're working on a new codebase or when you read code using an unfamiliar function, you'll see that a variable has the potential to change which may make the rest of the code easier to understand
Is this memory safe?
Not to be confused with automatic memory which completely works, memory safety is planned for the future.
Why is the compiler under an EULA instead of a popular license?
One issue we have right now is no one has heard of the project. There has been an instance of a cloud company forking an open source project and leading everyone to believe the company created the project. The team doesn't want to deal with anything like that or accidentally splinter the community ourselves (for example python 2 vs 3). For the moment the team would rather prevent forking so there won't be multiple communities with different organizations behind them.