81–90 of 98 posts
Earlier quoted context omitted.
Same here! It's very cool but my ideal use case would be on a limited ISA architecture like ESP32.
Bolt doesn’t support ARM or RISC. There’s some comments above re: the confusion with the term “embedded” and “real time”.
Run some examples, and it looks like this "High-performance, real-time optimized, super-fast" language is ~ 10 times slower than luajit ~ 3 times slower than lua 5.4
Looks cool, but please can we stop naming things ”bolt”
Yeah this is the third programming language named Bolt that I'm aware of
Bolt: a language with in-built data-race freedom! (recent discussion: https://news.ycombinator.com/item?id=23122973) - https://github.com/mukul-rathi/bolt
Bolt: A programming language for rapid application development - https://github.com/boltlang/Bolt
BOLT: a programming language that was desinged for begining programmers who have never seen code before in their life - https://sourceforge.net/projects/boltprogramming/files
I'm very much in favor of authors choosing unique names for programming languages because there's still plenty of good names up for grabs without having to step on someone's toes. If the project is dead, that's one thing; the data-race one was a research project and hasn't had any activity in 5 years. BOLT last modified in 2014.
But beariish/bolt and boltlang/bolt were started in the same year and are still under active development. With boltlang/bolt obviously snagging the namespace first, I think they should have claim to the name for now. That said, neither seems to have registered any domains, so whoever gets bolt-lang.org/com/net first will probably have an easier time defending a claim.
Earlier quoted context omitted.
I used brainfuck interpreter https://github.com/Beariish/bolt/blob/main/examples/bf.bolt vs lua / luajit implementations from https://github.com/kostya/benchmarks Just checked with nbody: - still 10 times slower than luajit - 2 times slower than luajit -joff - but 20% faster than lua 5.4 - but uses 47 Mb RAM vs 2.5 Mb for lua/luajit
I appreciate the followup here. The brainfuck interpreter isn't meant to be a benchmark notably, it's a naive implementation for the sake of the example. I did spot some poor code in the Bolt version of nbody that can be changed (the usage of `.each()` in the hot loop is creating loads of temporary iterators, that's the memory difference.) luajit -joff does perform better even with this change, but I observe closer t…
- 487.41 millis / 2364 kb ram for luajit -joff
- 770.17 millis / 41712 kb ram for bolt
770.17 / 487.41 ~~ 1.58 cpu, not 2x, but not 15% either
41712 / 2364 ~~ 17.64 ramI don't understand why people still choose the syntax `import xxx from yyy` in the current year. It is a major source of complaining for languages like python or javascript, because it makes autocomplete does not work well. make me instantly lost interest in the language.
Dynamically typed languages have more difficulties with autocomplete in general, Bolt is statically typed so you shouldn't automatically assume the same difficulties carry over.
Nice language! I am wondering how error handling / exceptions works in bolt? Quickly scanned the programming guide - but wasn't able to find it. Did i miss a section?
As far as i can see it is simple, everything can return an Error, so you have to check the return value if it is an error. https://github.com/Beariish/bolt/blob/main/examples/error_ha...
But I think OP was asking about whatever the hell this means by "native error callback" https://github.com/Beariish/bolt/blob/0.1.0/doc/Bolt%20Stand...
I like 99% of this, and the thing I don't like is in the very first line of the example: > import abs, epsilon from math IMHO it's wrong to put the imported symbols first, because the same symbol could come from two different libraries and mean different things. So the library name is pretty important, and putting it last (and burying it after a potentially long list of imported symbols) just feels wrong. I get that…
can't the compiler process it in reverse?
I like 99% of this, and the thing I don't like is in the very first line of the example: > import abs, epsilon from math IMHO it's wrong to put the imported symbols first, because the same symbol could come from two different libraries and mean different things. So the library name is pretty important, and putting it last (and burying it after a potentially long list of imported symbols) just feels wrong. I get that…
Do you think approaching the way typescript does it for Bolt is a reasonable compromise here? Bolt already supports full-module renames like import math as not_math So supporting something along the lines of import abs as absolute, sqrt as square_root from math Would be farily simple to accomplish.
from math import square_root as sqrt, abs as absolute
from math import * as not_math
Whereas the `import abs from math` often means you type `import` have no auto-complete for what comes next, maybe type ` from math` then cursor back to after the import to get auto-completion hints.
It's very similar to the arguments about how the SQL syntax is backwards for good auto-complete and a lot of people prefer things like PRQL or C# LINQ that take an approach like `from someTable where color = 'Red' select name` (rather than `select name from someTable where color = 'Red'`).
I love the concept -- I've often wished that lean languages like Lua had more support for static typing, especially given the potential performance benefits. I also love the focus on performance. I'm curious if you've considered using a tail call design for the interpreter. I've found this to be the best way to get good code out of the compiler: https://blog.reverberate.org/2021/04/21/musttail-efficient-i... Unfortun…
I did experiment with a few different dispatch methods before settling on the one in Bolt now, though not with tailcalls specifically. The approach I landed on was largely chosen cause it in my testing competes with computed goto solutions while also compiling on msvc, but I'm absolutely open to try other things out.
(Whether the blob uses computed gotos or loop-switch is less important these days, because Clang [but not GCC] is often smart enough to actually replicate your dispatch in the loop-switch case, avoiding the indirect branch prediction problem that in the past meant computed gotos were preferable. You do need to verify that this optimization actually happens, though, because it can be temperamental sometimes[1].)
By contrast, tail calls with the most important interprerer variables turned into function arguments (that are few enough to fit into registers per the ABI—remember to use regparm or fastcall on x86-32) give the compiler the opportunity to allocate registers for each bytecode’s body separately. This usually allows it to do a much better job, even if putting the cold path out of line is still advisable. (Somehow I’ve never thought to check if it would be helpful to also mark those functions preserve_none on Clang. Seems likely that it would be.)