▲ 9 ▼ Neugram - a scripting language integrated with Go

neugram.io posted by kenny 2364 days ago

I started working on Neugram because as I spent more time programming in Go I found myself writing a larger fraction of the scripts better suited to Python or Perl in Go. My daily programming came to be dominated by bash and Go.

The problem is, bash is an awkward language for a ~100 line program, and sometimes so is Go. While it is thoroughly enjoyable to use the same standard library in scripts as in big complex projects, Go is slower to work in than Python and Perl for a few reasons:

▲ kenny 2363 days ago ▼

I've adjusted the title after a comment from the author, as it's not a fork intended to diverge from the Go language so much as using it as a basis.

Contributing
▲ tomf 2364 days ago ▼
This is interesting, but seems a little unnecessarily complex in places. Not sure they need to stray so far from Go. You can pretty much do exactly the same thing in golang just with a check(err) function which panics instead (tried to paste this into this comment as code but the formatting wasn't so good (no newlines)).
https://play.golang.org/p/lUR3JvJIyu

The only lines saved by a whole new language are:
```
package main
```
```
func main() {
```
which is pretty superfluous I agree and nice to ditch (but could be handled by a preprocessor for scripts). And a line of error handling, which I much prefer explicit in pure go like this:
```
f, err := os.Create("hello.txt")
check(err)
```
Now a check function that just panics is only useful on short scripts, but it would seem easier to have explicit error handling than produce an entire new dialect for this.
Contributing
▲ kenny 2364 days ago ▼
Sorry about the code styling, it could do with some work.
I liked some of the ideas here, but agree it's a shame to completely hide error handling rather than just make it simpler. There's an interesting discussion of Go error handling for Go 2 here with lots of proposals. For scripts I guess it's fine to panic in most cases (though I feel like sometimes you'd want to handle it gracefully and tell the user), but even just some simpler syntax like on one line this would be nice:
```
f, err := os.Create("hello.txt")
return on err { println(err) }
```
I agree better to be explicit - I don't really like the spooky hidden errors in this proposed language. Fun to see people experimenting with different approaches though - I think it makes the tradeoffs a lot clearer when using go itself.
Contributing