Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–40 of 98 posts

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

#31

Post by driggs »

cookiengineer wrote: post #12

If functions don't have a return signature, does that mean everything must be satisfied in the compilation step? What about memory management/ownership? This would imply that everything must be copy by value in each function callsite, right? How to use references/pointers? Are they supported? I like the matchers which look similar to Rust, but I dislike the error handling because it is neither implicit, and neither e…

> If functions don't have a return signature, does that mean everything must be satisfied in the compilation step?

Functions do have a return signature.

It looks like the author chose to show off the feature of return type inference in the short example README code, rather than the explicit case.

https://github.com/Beariish/bolt/blob/main/doc/Bolt%20Progra...

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

#32

Post by debugnik »

haberman wrote: post #18

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…

You may be interested in Luau, which is the gradually-typed dialect of Lua maintained by Roblox. The game Alan Wake 2 also used it for level scripting.

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

#34

Post by jitl »

thrance wrote: 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.

It’s great in TypeScript. In TypeScript your source can have inferred types returned, and then use a build step to produce resolved typings files (.d.ts) for distribution that have the fully specified type.

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

#37

Post by vhodges »

perlgeek wrote: post #20

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…

According to the Programming Guide, it supports aliases for imports

"In case of conflict or convenience, you can give modules an alias as well."

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

#39

Post by beariish »

memophysic wrote: post #36

Looks great, I'm especially a fan of the more C and Python syntax. Lua works, but its syntax has always been bugging me. On the feature side, is there any support for breakpoints or a debugging server, and if not is it planned?

There's nothing like that right now, but it's absolutely something I want to explore in the future.

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

#40

Post by beariish »

astatine wrote: post #35

This looks awesome. Would you have any data on the performance of large number of invocations of small scripts? I am wondering at startup overhead for every script run. which the 500kloc/s may not capture well.

It depends on your exact usecase, I'm not 100% sure what you're asking. There is some overhead for invoking the compiler on a per-script basis. If you're parsing once but running a script many times, Bolt provides some tools (like reusing a preallocated thread object) to ammortize that cost
Post reply on HN