Live data from Hacker News

Show HN: Bolt – A super-fast, statically-typed scripting language written in C

github.com

51–60 of 98 posts

Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C

#52

I was quite excited by the description and then I noted that Bolt heavily relies on double floating point numbers. I am quite disappointed because this doesn't allow me to use Bolt in my context: embedded systems where floating point numbers are rarely supported... So I realized that I misinterpreted `embedded`.

Same here! It's very cool but my ideal use case would be on a limited ISA architecture like ESP32.

Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C

#54

FYI "the embedded scene" is likely to be interpreted as "embedded systems" rather than "embedded interpreters" even by people who know about embedded interpreters, especially since all the languages you give as an example have been attempted for use on those targets (micropython, lua, and even typescript)

True. I misread it as being for embedded, especially with the term "real-time" in the mix. Then later when there was no ARM or RISC-V support I became very confused.

Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C

#55

Congrats! I think this could be quite useful for me. I noticed that `let`-declared variables seem to be mutable. I'd strongly recommend against that. Add a `var` keyword.

Seems to be the worst of both worlds: mutable by default, and one must add a "const" keyword to the "let", disincentivizing const behavior by making it super verbose (e.g. the "final" problem from Java)

https://github.com/Beariish/bolt/blob/0.1.0/doc/Bolt%20Progr...

Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C

#56
post #9
post #7

Function return type inference is funny but I don't think it's that great of a feature. It makes it harder for a library's consumer to know how to properly use a function, and it also makes it harder for the maintainer to not break backwards compatibility inadvertently. Anyway, I'm all for experimenting.

There's nothing stopping a library author from explicitly annotating return types wherever a stable interface is important, the idea is more for smaller functions or callbacks to make use of this. Perhaps I'll make the examples clearer to reflect the intention.

Perhaps it makes more sense to say that exported function interfaces be explicit. That forces you to document the api and more carefully consider changes.

Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C

#57

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?

Re: Show HN: Bolt – A super-fast, statically-typed scripting language written in C

#59
This looks so familiar that it got me thinking: who is collating all of the languages that are being invented? I must see two dozen a year on HN. I'm not dissing OP, but I've seen so many languages I'm not sure if I'm having deja vu, or vuja de.
Post reply on HN