Earlier quoted context omitted.
Windows is crippled somewhat on that front, but there are workarounds. Often easier and way more functional to just install a wrapper like ptpython, bpython, ipython, etc.
I'm using a Mac.
[deleted]
Yaegi – Yet Another Go Interpreter
71–77 of 77 posts
Re: Yaegi – Yet Another Go Interpreter
#72Around a ~6MB interpreter for those curious, not bad.
Generally the Go runtime (garbage collector, scheduler, allocator, etc) alone is 2-5MB, for additional context.
a bit less:
$ cat > t.go
package main
func main() {}
$ go build t.go
$ ls -l t
-rwxr-xr-x 1 f2f staff 1101432 24 Jul 23:19 tRe: Yaegi – Yet Another Go Interpreter
#73Why would I need a Go Interpreter? What advantage does it provide over using a precompiled binary?
The most obvious use for this is to distribute an application with a scripting interface.
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.
Re: Yaegi – Yet Another Go Interpreter
#74Earlier quoted context omitted.
Generally the Go runtime (garbage collector, scheduler, allocator, etc) alone is 2-5MB, for additional context.
a bit less: $ cat > t.go package main func main() {} $ go build t.go $ ls -l t -rwxr-xr-x 1 f2f staff 1101432 24 Jul 23:19 t
And you can drop that down to ~775k by using `strip`.
[rjp@hostname tmp]$ ls -l gosize
-rwxr-xr-x 1 rjp rjp 1126905 Jul 25 07:00 gosize
[rjp@hostname tmp]$ strip gosize
[rjp@hostname tmp]$ ls -l gosize
-rwxr-xr-x 1 rjp rjp 793704 Jul 25 07:00 gosize
[rjp@hostname tmp]$ go version
go version go1.12.7 linux/amd64Re: Yaegi – Yet Another Go Interpreter
#75Earlier quoted context omitted.
Generally the Go runtime (garbage collector, scheduler, allocator, etc) alone is 2-5MB, for additional context.
a bit less: $ cat > t.go package main func main() {} $ go build t.go $ ls -l t -rwxr-xr-x 1 f2f staff 1101432 24 Jul 23:19 t
Not sure, but is it possible that the runtime (or parts thereof) isn’t linked in in that example?
Re: Yaegi – Yet Another Go Interpreter
#76Earlier quoted context omitted.
I disagree with this to some extent. Unit tests are a pretty good poor-mans REPL in languages that don't have REPLs. For instance, I've seen people write fake unit tests to do things like query a database for analysis purposes; it was just the fastest way they could come up with to do the exploratory work. What makes a unit test a good poor-mans REPL in a language like java with an IDE is: * Java IDEs, especially ecl…
We are talking Go here, which has a fast compiler. The IDE integration isn't always as good as Java, though.
Go has a fast compiler but to my knowledge has zero support for incremental compilation. It has to recompile the entire project, transitively with all its dependencies, before you can run your code modification. I haven't code in go, but IMO this does not scale well as projects grow in size.
Re: Yaegi – Yet Another Go Interpreter
#77Earlier quoted context omitted.
I disagree with this to some extent. Unit tests are a pretty good poor-mans REPL in languages that don't have REPLs. For instance, I've seen people write fake unit tests to do things like query a database for analysis purposes; it was just the fastest way they could come up with to do the exploratory work. What makes a unit test a good poor-mans REPL in a language like java with an IDE is: * Java IDEs, especially ecl…
Unit tests are a pretty good poor-mans REPL in languages that don't have REPLs. Java IDEs, especially eclipse, are amazing at fast, incremental compilation. You make one change, and then only recompile what you need to. I always found this lugubrious compared to the experience in many Smalltalks. The Java vs. Smalltalk USENET flame wars in the 90's were partly motivated by the downgrade in developer UX caused by the…
The JVM is less dynamic in its ability to reload code, but the payoff is that java code can be 10-100x faster than smalltalk code. I personally think the performance gain is worth it. Hotspot has some limited support for hot code reloading, which is a pre-requisite to being able to "code in your debugger", but it's limited enough that I don't bother with it. Alternatively, you can code in a dynamic language on the JVM such as JRuby or Clojure and have full support for "coding in the debugger". These languages are also a lot slower than Java.