Golang

2191 readers
1 users here now

This is a community dedicated to the go programming language.

Useful Links:

Rules:

founded 1 year ago
MODERATORS
1
 
 

I'm fairly new to go and I've recently migrated a in-memory cache from node to go for concurrency improvements, but the memory usage difference between the two are huge. I've tried to read up on the map memory model in go but haven't been able to find a reason for the difference. I can't see that I'm doing anything special, so I'm looking for guidance here.

The documents that are stored are around 8 KB in size as a JSON file. In node the memory usage for 50000 documents stored as objects is 1,5 GB, and for go maps it is 10 GB.

To me, this doesn't seem reasonable but I can't find the source of the difference. Could anyone here give their take on this?

2
3
4
5
6
 
 

In the original proof of concept for ranging over functions, iter.Pull was implemented via goroutines and channels, which has a massive overhead.

When I dug in to see what the released code did I was delighted to see that the go devs implemented actual coroutines to power it. Which is one of the only ways to get sensible performance from this.

Will the coro package be exposed as public API in the future? Here's to hoping ♥️

7
8
 
 

Always choose the right tool for the job? Nah. I use Go basically everywhere, which either makes me insightful or stupid. Decide for yourself! :D

9
 
 

On my work I'm always switching between databases and kind of tired on UX differences between psql, mysql, sqlite3. So, I'm making a small set of tools for myself in tries to solve that. It's kinda works for me already and I'd like to share it here :)

10
11
12
13
 
 

I made some Go scripts that require user input fmt.Scanln(&fileName) during the execution. When I use the Go debugger built into VSCode which is the launch type, it works but there is no way to enter any prompts when your exeuctable asks for a input. With other programming languages like NodeJS and PHP, there is way to run the scripts in "debugging mode" where it will run the code but before it executes the code, it will wait to attach to a debugger on your system and then execute the code. This has always allowed me to use the terminal for inputs in the executable.

For example to do this in NodeJS, you will use node --inspect-brk=0.0.0.0 main.js instead of node main.js and then run the debugger in VSCode to attach it to the executing script. Is there a way to do this with Go? Do I need to set something up to achieve this?

I am on Linux Mint and cannot find any commands to run go run . but to wait for a debugger to attach to the executable before executing.

14
15
 
 

cross-posted from: https://discuss.online/post/8349829

Hello,

We're looking for GoLang contributors to help with the federation service. We're happy to have people that contribute code or help with code reviews.

If you know anyone or if you're interested please reach out!

Email: hello@sublinks.org Mastodon: https://utter.online/@sublinks Online form: https://sublinks.org/join_organization.html

Thanks, jgrim

16
17
 
 

I've seen that a new "range-over-func" experiment is available with Go 1.22. In this article, I took a closer look and evaluated the feature for myself.

18
19
 
 

Oh no, not another 'Is Rust better than Go?' article. Seriously, haven't we all had our fill of these comparisons by now? But before you sigh in exasperation, hear us out!

20
21
22
 
 

In this article we’ll explore a package called script that aims to sprinkle some Unix shell fairy dust on your Go programs.

23
 
 

I’ve been using this to execute Go “scripts” in CI pipelines where Bash just doesn’t cut it. It’s an interpreter for Go. It can be used to treat Go code like a “script,” rather than a compiled application. It is also able to be imported into a Go program and used to load up Go code dynamically at run time (think “loading plugins” with Go!).

From the readme:

release Build Status GoDoc

Yaegi is Another Elegant Go Interpreter. It powers executable Go scripts and plugins, in embedded interpreters or interactive shells, on top of the Go runtime.

Features

  • Complete support of Go specification
  • Written in pure Go, using only the standard library
  • Simple interpreter API: New(), Eval(), Use()
  • Works everywhere Go works
  • All Go & runtime resources accessible from script (with control)
  • Security: unsafe and syscall packages neither used nor exported by default
  • Support the latest 2 major releases of Go (Go 1.19 and Go 1.20)

Install

Go package

import "github.com/traefik/yaegi/interp"

Command-line executable

go install github.com/traefik/yaegi/cmd/yaegi@latest

Note that you can use rlwrap (install with your favorite package manager), and alias the yaegi command in alias yaegi='rlwrap yaegi' in your ~/.bashrc, to have history and command line edition.

CI Integration

curl -sfL https://raw.githubusercontent.com/traefik/yaegi/master/install.sh | bash -s -- -b $GOPATH/bin v0.9.0

Usage

As an embedded interpreter

Create an interpreter with New(), run Go code with Eval():

package main

import (
	"github.com/traefik/yaegi/interp"
	"github.com/traefik/yaegi/stdlib"
)

func main() {
	i := interp.New(interp.Options{})

	i.Use(stdlib.Symbols)

	_, err := i.Eval(`import "fmt"`)
	if err != nil {
		panic(err)
	}

	_, err = i.Eval(`fmt.Println("Hello Yaegi")`)
	if err != nil {
		panic(err)
	}
}

Go Playground

As a dynamic extension framework

The following program is compiled ahead of time, except bar() which is interpreted, with the following steps:

  1. use of i.Eval(src) to evaluate the script in the context of interpreter
  2. use of v, err := i.Eval("foo.Bar") to get the symbol from the interpreter context, as a reflect.Value
  3. application of Interface() method and type assertion to convert v into bar, as if it was compiled
package main

import "github.com/traefik/yaegi/interp"

const src = `package foo
func Bar(s string) string { return s + "-Foo" }`

func main() {
	i := interp.New(interp.Options{})

	_, err := i.Eval(src)
	if err != nil {
		panic(err)
	}

	v, err := i.Eval("foo.Bar")
	if err != nil {
		panic(err)
	}

	bar := v.Interface().(func(string) string)

	r := bar("Kung")
	println(r)
}

Go Playground

As a command-line interpreter

The Yaegi command can run an interactive Read-Eval-Print-Loop:

$ yaegi
> 1 + 2
3
> import "fmt"
> fmt.Println("Hello World")
Hello World
>

Note that in interactive mode, all stdlib package are pre-imported, you can use them directly:

$ yaegi
> reflect.TypeOf(time.Date)
: func(int, time.Month, int, int, int, int, int, *time.Location) time.Time
>

Or interpret Go packages, directories or files, including itself:

$ yaegi -syscall -unsafe -unrestricted github.com/traefik/yaegi/cmd/yaegi
>

Or for Go scripting in the shebang line:

$ cat /tmp/test
#!/usr/bin/env yaegi
package main

import "fmt"

func main() {
	fmt.Println("test")
}
$ ls -la /tmp/test
-rwxr-xr-x 1 dow184 dow184 93 Jan  6 13:38 /tmp/test
$ /tmp/test
test

Documentation

Documentation about Yaegi commands and libraries can be found at usual godoc.org.

Limitations

Beside the known bugs which are supposed to be fixed in the short term, there are some limitations not planned to be addressed soon:

  • Assembly files (.s) are not supported.
  • Calling C code is not supported (no virtual "C" package).
  • Directives about the compiler, the linker, or embedding files are not supported.
  • Interfaces to be used from the pre-compiled code can not be added dynamically, as it is required to pre-compile interface wrappers.
  • Representation of types by reflect and printing values using %T may give different results between compiled mode and interpreted mode.
  • Interpreting computation intensive code is likely to remain significantly slower than in compiled mode.

Go modules are not supported yet. Until that, it is necessary to install the source into $GOPATH/src/github.com/traefik/yaegi to pass all the tests.

Contributing

Contributing guide.

License

Apache 2.0.

24
 
 

Always interesting to hear different points of view on this subject. Personally I think mocks make sense to capture complex sets of interactions or otherwise difficult to reach error conditions, so I don't think it's a do or do-not kind of thing.