Playing around, it seems to have problems assigning int literals to int8 variables, and it seems to sometimes have problems re-assigning pointer values.
I would have expected a honest benchmark result. Which will be much worse than 6%.
Which is totally fine! an interpreter will of course be much slower. But this seems like the wrong kind of marketing by omission to me.
Dunno what's wrong with your readline but what you describe is default Python behavior. Try installing ipython, you'll get all that and more (such as syntax highlighting, multi-line editing, and much more).
and /home/mbarkhau/bin/ipy is this
/home/mbarkhau/miniconda3/envs/py37/bin/ipython -i -c import itertools as it; from statistics import ;import functools as ft;import operator as op;import io;import pathlib as pl;import pandas as pd;import numpy as np;import typing as typ;from math import ;import enum;import re;import sys;import os;import ujson as json;import collections;import random;import decimal;import fractions;import time;import datetime as dt;"
I must use it dozens of times a day.
Ipython has interactive tab completion (including for imports and locally defined symbols), syntax highlighting, (sane) auto indenting, all in the REPL. It's the foundation of jupyter notebooks.
Something that blew my mind recently was using a Lisp repl which was integrated with my text editor.
I just wrote out the code I wanted to toy with in my text editor buffer, and then highlighted it and hit a key command to evaluate it at the repl without even needing to switch over to the repl window.
It would be so cool if we had great support for something similar in non Lisp languages.
Nowadays I find repl driven approach to be not so sustainable for mid to large sizes of teams.
It is fun on small/personal projects though.
Surely those are programming practices that don't need to go hand-in-hand.
Users can write simple scripts which change behaviour, or react to events, without needing to learn a toy-language, or even necessarily have a compiler setup.
In a "scripting" scenario, you can load some golang code at runtime without needing to bring the full golang compiler toolchain along, which keeps the nice "single binary" deploys of golang. It may be possible to sandbox scripts as well (though I haven't looked into how that could work with this implementation), which could reduce the risk of running scripts (less likely to shoot yourself in the foot. Probably not a security boundary -just look at how much work goes into safe JS in browsers to have that).
