imported>Justin: Created page with "# The Decision Updated: 1/10/19 - C or C++ with no external dependencies for low level tools, such as data processing, etc. - TypeScript for high level operations and the us..."

2019-01-14T22:56:01Z

Created page with "# The Decision Updated: 1/10/19 - C or C++ with no external dependencies for low level tools, such as data processing, etc. - TypeScript for high level operations and the us..."

New page

# The Decision

Updated: 1/10/19

- C or C++ with no external dependencies for low level tools, such as data processing, etc.
- TypeScript for high level operations and the user interface.

## Rationale

These are points that we learned from experience working with node, chicken, and C++.

### Why C++?
- C++ is well integrated with node. You can create packages with C and C++ and the cross platform build system will compile them.
- It turned out to be a massive pain to maintain multiple interpreters and sets of packages for all three platforms. Portable C and C++ code "just works". The effort spent in maintaining TypeScript makes it worth it to use it more places.

### Why Not Chicken
- We thought using chicken for tools would be a good idea, but what we didn't know at the time was that it offers benefits remarkably similar to JavaScript. Scheme is undoubtedly a better language, but the benefits of mixing both are marginal.
- The lack of static typing in JavaScript turned out to be a problem when our project got too large. TypeScript has made our project much more robust and easy to change. Chicken would not have helped here.
- It increased the file size by about 15 mb for a HelloWorld.

## The Original Discussion

## Language Requirements
- ability to create small unix friendly programs which can work with other unix tools.
- good platform support for mac, linux, and windows. (filesystem, http, etc)
- Alpheus and I want to work with it.
- Easy to distribute with our program. In other words, it does not require installation.
- nice if we could use it server side (JS and node is always a fallback)
- ??? Must be able to distribute binaries not original source code

### Other considerations
As Tom has pointed out we don't want a cornucopia of languages. This is difficult to maintain and hard to share information for.
However, Alpheus are not afraid of switching between a few, especially when they are the right tool for the job.

# Discussion

## 1.Go
Go compiles to small standalone binaries. It has fast startup and execution times making it a good choice for unix tools.
However of these languages we are considering, We don't know a ton about Go. There are small complaints we have with its design,
but it will surely get the job done. It is both a server side and client side langauge.

## 2.Scheme
Chicken scheme compiles to small standalone binaries. It has fast startup and execution times making it a good choice for unix tools.
Alpheus and I both love Lisps. It has good platform and library support through the egg package system.
It is both a server side and client side langauge.

Alpheus wanted to add that one anecdote that makes Scheme in general (and probably Chicken Scheme in
particular) is an anecdote from someone on Reddit (who, incidentally, couldn't get into too much detail
about his project for IP reasons) who explained that they were initially doing their development in two
stages: using Python for prototyping, and C for the final product, which needed to work on a
microcontroller. They were running into certain difficulty with this tool chain, and decided to give
Scheme a whirl -- it took three days to convert the Python code to Scheme, and another three days to
figure out how to compile it to C and get it working with their microcontroller -- but when they were
finished, they had something that was just as easy to prototype in as Python, but was running almost
as fast as what they had in C.

Alpheus finds this combination of flexibility and speed particularly compelling.

## Rust
Don't know much about it, complex type systems.

## D
Don't know much about it.

## ~~C++~~
Alpheus hates it. He also hates Perl and PHP (for arguably similar reasons...)

## ~~C~~
Cross platform support will be tedious and error prone. Potentially a fallback.

## ~~Haskell~~
Interesting, but an imperative style is probably more appropriate for the package management. Bad windows support.

## ~~Swift/Objective-C~~
Cross platform langauge support, but bad cross platform library support.

## JVM Langauges
We don't love them. They have also have distribution and start up problems, but it is compiled and well supported. It could get the job done though.

Alpheus prefers Scala. Justin would prefer Clojure. We could use Java too.

## Node
Node is already included with Electron. (It is in a library and we may have to make an executable)
So it would be easy to write Javascript. However, Node has very slow startup times due to the large number of pacakges it must JIT compile.
This makes it somewhat of a pain to use as a unix tool. The actual execution time is pretty fast. According to some simple benchmarks it
is several times faster than CPython and slightly faster the PyPy. An example of these characteristics can be found in Gulp.
The startup time for each command is close to a second, but the actual execution time is small.

Also, apparently the person who created Node generally prefers Go.

### A note on Transpiling to JS:
We aren't bothered by JS enough to make transpiling from a slightly different syntax (python, typescript, etc) worth it.
If we use Node we will write JS. (However, ParenScript is the most compelling since it actually opens up more powerful structures.)

## ~~Python~~
Alpheus and I both like Python; however, it would be a pain to distribute. We would have to include the entire Python runtime in the app,
and keep it up to date alongside electron. Additionally distribution would include raw .py files.

## ~~Rholang~~

This would be a fantastic language to use, except for the fact that it is very immature, and doesn't yet
have the features we need to get things to work. It annoys Alpheus deeply that we don't yet have a
"Pull-From-Future" Compiler that can get a fully-featured working Rholang compiler for us to use for
this project.

Project-langauges - Revision history

imported>Justin: Created page with "# The Decision Updated: 1/10/19 - C or C++ with no external dependencies for low level tools, such as data processing, etc. - TypeScript for high level operations and the us..."