Backward compatibility in Go: discussion
>>>
We now have about ten years of experience with Go 1 compatibility.
In general it works very well for the Go team and for users. However, there are also practices we've developed since then that it doesn't capture (specifically GODEBUG settings), and there are still times when users’ programs break.
I think it is worth extending our approach to try to break programs even less often, as well as to explicitly codify GODEBUG settings and clarify when they are and are not appropriate.
>>>
by Russ Cox
Join the discussion if you wish https://github.com/golang/go/discussions/55090Backward compatibility in Go: discussion
>>>
We now have about ten years of experience with Go 1 compatibility.
In general it works very well for the Go team and for users. However, there are also practices we've developed since then that it doesn't capture (specifically GODEBUG settings), and there are still times when users’ programs break.
I think it is worth extending our approach to try to break programs even less often, as well as to explicitly codify GODEBUG settings and clarify when they are and are not appropriate.
>>>
by Russ Cox
Join the discussion if you wish https://github.com/golang/go/discussions/55090
>>>
We now have about ten years of experience with Go 1 compatibility.
In general it works very well for the Go team and for users. However, there are also practices we've developed since then that it doesn't capture (specifically GODEBUG settings), and there are still times when users’ programs break.
I think it is worth extending our approach to try to break programs even less often, as well as to explicitly codify GODEBUG settings and clarify when they are and are not appropriate.
>>>
by Russ Cox
Join the discussion if you wish https://github.com/golang/go/discussions/55090Backward compatibility in Go: discussion
>>>
We now have about ten years of experience with Go 1 compatibility.
In general it works very well for the Go team and for users. However, there are also practices we've developed since then that it doesn't capture (specifically GODEBUG settings), and there are still times when users’ programs break.
I think it is worth extending our approach to try to break programs even less often, as well as to explicitly codify GODEBUG settings and clarify when they are and are not appropriate.
>>>
by Russ Cox
Join the discussion if you wish https://github.com/golang/go/discussions/55090
GitHub
extending Go backward compatibility · golang/go · Discussion #55090
This discussion is about backward compatibility, meaning new versions of Go compiling older Go code. For the problem of old versions of Go compiling newer Go code, see this other discussion about f...
October 14, 2022
November 1, 2022
Let’s talk about logging
This is a post inspired by a thread that Nate Finch started on the Go Forum. This post focuses on Go, but if you can see your way past that, I think the ideas presented here are widely applicable.
https://dave.cheney.net/2015/11/05/lets-talk-about-logging
This is a post inspired by a thread that Nate Finch started on the Go Forum. This post focuses on Go, but if you can see your way past that, I think the ideas presented here are widely applicable.
https://dave.cheney.net/2015/11/05/lets-talk-about-logging
Go Forum
What's so bad about the stdlib's log package?
I see a lot of hate directed at the stdlib’s log package, and of course, there are a medley of third party logging packages. What are people’s problems with the standard log package? I’ve seen accusations that it doesn’t have leveled logging, which seems…
November 9, 2022
Error handling in Go is a little different than other mainstream programming languages like Java, JavaScript, or Python. Go’s built-in errors don’t contain stack traces, nor do they support conventional try/catch methods to handle them. Instead, errors in Go are just values returned by functions, and they can be treated in much the same way as any other datatype - leading to a surprisingly lightweight and simple design.
In this article, Brandon Schurman demonstrates the basics of handling errors in Go, as well as some simple strategies you can follow in your code to ensure your program is robust and easy to debug.
https://earthly.dev/blog/golang-errors/
In this article, Brandon Schurman demonstrates the basics of handling errors in Go, as well as some simple strategies you can follow in your code to ensure your program is robust and easy to debug.
https://earthly.dev/blog/golang-errors/
Earthly Blog
Effective Error Handling in Golang
Learn how to effectively handle errors in Go with this informative article. Discover the basics of error handling in Go, strategies for robust code...
December 22, 2022
March 26, 2023
package main
import "fmt"
func main() {
// create an array with fixed length
var numbers [5]int
fmt.Println("Empty array:", numbers)
// assign values to the array
numbers[0] = 1
numbers[1] = 2
numbers[2] = 3
numbers[3] = 4
numbers[4] = 5
fmt.Println("Assigned array:", numbers)
// create an array with values in one line
letters := [4]string{"a", "b", "c", "d"}
fmt.Println("Letters array:", letters)
// get length of an array
fmt.Println("Length of numbers array:", len(numbers))
// access an array element
fmt.Println("First element of numbers array:", numbers[0])
// iterate over an array
for i, number := range numbers {
fmt.Printf("Element %d is %d\n", i, number)
}
}
import "fmt"
func main() {
// create an array with fixed length
var numbers [5]int
fmt.Println("Empty array:", numbers)
// assign values to the array
numbers[0] = 1
numbers[1] = 2
numbers[2] = 3
numbers[3] = 4
numbers[4] = 5
fmt.Println("Assigned array:", numbers)
// create an array with values in one line
letters := [4]string{"a", "b", "c", "d"}
fmt.Println("Letters array:", letters)
// get length of an array
fmt.Println("Length of numbers array:", len(numbers))
// access an array element
fmt.Println("First element of numbers array:", numbers[0])
// iterate over an array
for i, number := range numbers {
fmt.Printf("Element %d is %d\n", i, number)
}
}
March 26, 2023
March 26, 2023
package main
import (
"fmt"
"log"
"net/http"
)
func main() {
// Define the HTTP handler function for our microservice
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Hello, World!")
})
// Start the microservice and listen for requests on port 8080
log.Fatal(http.ListenAndServe(":8080", nil))
}
import (
"fmt"
"log"
"net/http"
)
func main() {
// Define the HTTP handler function for our microservice
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Hello, World!")
})
// Start the microservice and listen for requests on port 8080
log.Fatal(http.ListenAndServe(":8080", nil))
}
March 26, 2023
March 26, 2023
User or *User - Do We Need Struct Pointers Everywhere?
The answer, as you might’ve guessed, is “no.” But, it’s also more nuanced due to the lifetime of a struct, its usage, and other aspects that boil this down to general guidelines and case-by-case analysis.
https://preslav.me/2023/02/06/golang-do-we-need-struct-pointers-everywhere/
The answer, as you might’ve guessed, is “no.” But, it’s also more nuanced due to the lifetime of a struct, its usage, and other aspects that boil this down to general guidelines and case-by-case analysis.
https://preslav.me/2023/02/06/golang-do-we-need-struct-pointers-everywhere/
Preslav Rachev
User or *User - Do We Need Struct Pointers Everywhere?
A bit of up-front thinking can help make our Go code cleaner and more performant.
March 26, 2023
November 12, 2023
November 12, 2023
November 13, 2023
November 13, 2023
November 13, 2023
December 23, 2023
Interactive Go interpreter and debugger with generics and macros:
https://github.com/cosmos72/gomacro
@go_lang
https://github.com/cosmos72/gomacro
@go_lang
GitHub
GitHub - cosmos72/gomacro: Interactive Go interpreter and debugger with REPL, Eval, generics and Lisp-like macros
Interactive Go interpreter and debugger with REPL, Eval, generics and Lisp-like macros - cosmos72/gomacro
March 9, 2024