well.com is part of the decentralized social network powered by Mastodon.
This server is provided by The WELL (Whole Earth 'Lectronic Link), an extraordinary online community since 1985. Come visit us at https://www.well.com

Administered by:

Server stats:

41
active users

Learn more

#golang

14 posts14 participants2 posts today

Recently decided to give #golang another flex, and at the same time do something worthwhile: Help out with fixing stuff for @codeberg
Found a nice little issue to cut my teeth on.

I keep seeing #job descriptions asking for experience in “modern #programming languages” and then listing #Python (1991), #Java (1995), JavaScript (1995), #GoLang (2009), and/or #Rust (2012) in the same breath. That's a hell of a spread for modernity!

Unless, of course, they mean “used by ‘modern’ #developers,” in which case, cue the music!

(to the tune of “I Am the Very Model of a Modern Major-General” from Gilbert and Sullivan’s “The Pirates of Penzance”) (1/7)

Random though: #GoLang allows any letter in identifiers, so you can have a variable called (yes, ideographs are letters), but you can't have a CJK exported identifier, because the first letter of those has to be an uppercase letter, and those only exist for alphabets… weird asymmetry

#BoltDB is a Go rewrite of #LMDB (mostly; it has a lot more limitations). It's no longer maintained. Since 2021 some forks had a backdoor giving remote command access to machines.

snyk.io/blog/go-malicious-pack

All of this is inconceivable for LMDB, since it has no other dependencies. Also, the thought of an embedded DB engine having access to any networking APIs at all is just mindboggling.

The Go build system, and its automatic pulling of dependencies from github, is ludicrous.

Snyk | Developer Security Platform
Snyk · Do not pass GO - Malicious Package Alert | SnykRecently, researchers have found another Software Supply Chain issue in BoltDB, a popular database tool in the Go programming environment. The BoltDB Go Module was found backdoored and contained hidden malicious code.

It's easier to write code in ES6 (modern JavaScript) than in Go.

Yet I will not be writing any more ES6 when I have a choice, and will be writing Go instead.

Why? Because the cost of maintaining software soon outgrows the cost of having written it, and maintaining ES6 in the NPM infrastructure is intolerable.

I'd rather take the up-front hit to write code that's going to keep working next week, next year and next decade.

Is there a good, modern instance out there of a tutorial/project with shared Protobuf types being integrated into a Go project that depends on those types?

e.g. I have a Go repo github.com/organization/application1, which depends on types from github.com/organization/protos. Assume I may also have a Python repo github.com/organization/application2, which also depends on the protos.

Full soup to nuts. None of this handwaving through the important parts, which is pervasive in virtually every StackOverflow link that shows up when searching for related details. It should include explanations for where and how code gets generated.

It’s astonishing (not in the good way) that this is not documented anywhere on protobuf.dev.