Gno language

Related tags

Cryptography gno


At first, there was Bitcoin, out of entropy soup of the greater All. Then, there was Ethereum, which was created in the likeness of Bitcoin, but made Turing complete.

Among these were Tendermint and Cosmos to engineer robust PoS and IBC. Then came Gno upon Cosmos and there spring forth Gnoland, simulated by the Gnomes of the Greater Resistance.

Language Features

  • Like interpreted Go, but more ambitious.
  • Completely deterministic, for complete accountability.
  • Transactional persistence across data realms.
  • Designed for concurrent blockchain smart contracts systems.


Update Feb 13th, 2021: Implemented Logos UI framework.

This is a still a work in a progress, though much of the structure of the interpreter and AST have taken place. Work is ongoing now to demonstrate the Realm concept before continuing to make the tests/files/*.go tests pass.

Make sure you have >=go1.15 installed, and then try this:

> git clone [email protected]:gnolang/gno.git
> cd gno
> go mod download
> go test tests/*.go -v -run="Test/realm.go"


In Gno, all objects are automatically persisted to disk after every atomic "transaction" (a function call that must return immediately.) when new objects are associated with a "ownership tree" which is maintained overlaying the possibly cyclic object graph. The ownership tree is composed of objects (arrays, structs, maps, and blocks) and derivatives (pointers, slices, and so on) with struct-tag annotations to declare the ownership tree.

If an object hangs off of the ownership tree, it becomes included in the Merkle root, and is said to be "real". The Merkle-ized state of reality gets updated with state transition transactions; during such a transaction, some new temporary objects may "become real" by becoming associated in the ownership tree (say, assigned to a struct field or appended to a slice that was part of the ownership tree prior to the transaction), but those that don't get garbage collected and forgotten.

type Node interface {

type InnerNode struct {
	Key       Key
	LeftNode  Node `gno:owned`
	RightNode Node `gno:owned`

type LeafNode struct {
	Key       Key  `gno:owned`
	Value     interface{}

In the above example, some fields are tagged as owned, and some are not. An InnerNode structure may own a LeftNode and a RightNode, and it may reference or own a Key. The Key is already owned by the left most LeafNode of the right tree, so the InnerNode cannot own it. The LeafNode can contain a reference or own any value. In other words, if nobody else owns a value, the LeafNode will.

We get a lack-of-owner problem when the ownership tree detaches an object referred elsewhere (after running a statement or set of statements):

    A, A.B, A.C, and D are owned objects.
    D doesn't own C but refers to it.

	   (A)   (D)
	   / \   ,
	  /   \ ,
	(B)   (C)

    > A.C = nil

	   (A)       (D)
	   / \       ,
	  /   \     ,
	(B)    _   C <-- ?


  1. unaccounted object error (default)
  • can't detach object unless refcount is 0.
  • pushes problem to ownership tree manipulation logic.
  • various models are possible for maintaining the ownership tree, including reference-counting (e.g. by only deleting objects from a balanced search tree when refcount reaches 1 using a destroy callback call); or more lazily based on other conditions possibly including storage rent payment.
  • unaccounted object error detection is deferred until after the transaction, allowing objects to be temporarily unaccounted for.
  1. Invalid pointer
  • basically "weak reference pointers" -- OK if explicit and exceptional.
  • across realms it becomes a necessary construct.
  • will implement for inter-realm pointers.
  1. Auto-Inter-Realm-Ownership-Transfer (AIR-OT)
  • within a realm, refcounted garbage collection is sufficient.
  • automatic ownership transfers across realms may be desirable.
  • requires bidirectional reference tracking.


Gno is designed with blockchain smart contract programming in mind. A smart-contract enabled blockchain is like a massive-multiuser-online operating-system (MMO-OS). Each user is provided a home package, for example "". This is not just a regular package but a "realm package", and functions and methods declared there have special privileges.

Every "realm package" should define at last one package-level variable:

package alice
var root interface{}

func UpdateRoot(...) error {
  root = ...

Here, the root variable can be any object, and indicates the root node in the data realm identified by the package path "".

Any number of package-level values may be declared in a realm; they are all owned by the package and get merkle-hashed into a single root hash for the package realm.

The gas cost of transactions that modify state are paid for by whoever submits the transaction, but the storage rent is paid for by the realm. Anyone can pay the storage upkeep of a realm to keep it alive.

Merkle Proofs

Ultimately, there is a single root hash for all the realms.

From hash.go:

// ValueHash
// The ValueHash of a typed value is a unique deterministic
// accountable fingerprint of that typed value, and can be used
// to prove the value or any part of its value which is
// accessible from the Gno language.
// `ValueHash := lh(ValueImage)`
// `ValueImage:`
//   `= 0x00` if nil value.
//   `= 0x01,varint(.) if fixed-numeric.
//   `= 0x02,sz(bytes)` if variable length bytes.
//   `= 0x03,sz(TypeID),vi(*ptr)` if non-nil ptr.
//   `= 0x04,sz(OwnerID),sz(ElemsHash),mod,ref` if object.
//   `= 0x05,vi(base),off,len,max if slice.
//   `= 0x06,sz(TypeID)` if type.
// `ElemsHash:`
//   `= lh(ElemImage)` if object w/ 1 elem.
//   `= ih(eh(Left),eh(Right))` if object w/ 2+ elems.
// `ElemImage:`
//   `= 0x10` if nil interface.
//   `= 0x11,sz(ObjectID),sz(TypeID)` if borrowed.
//   `= 0x12,sz(ObjectID),sz(TypedValueHash)` if owned.
//   `= 0x13,sz(TypeID),sz(ValueHash)` if other.
//    - other: prim/ptr/slice/type/typed-nil.
//    - ownership passed through for pointers/slices/arrays.
// `TypedValueHash := lh(sz(TypeID),sz(ValueHash))`
// * eh() are inner ElemsHashs.
// * lh() means leafHash(x) := hash(0x00,x)
// * ih() means innerHash(x,y) := hash(0x01,x,y)
// * pb() means .PrimitiveBytes().
// * sz() means (varint) size-prefixed bytes.
// * vi() means .ValueImage().Bytes().
// * off,len,max and other integers are varint encoded.
// * len(Left) is always 2^x, x=0,1,2,...
// * Right may be zero (if len(Left+Right) not 2^x)
// If a pointer value is owned (e.g. field tagged "owned"), the
// pointer's base if present must not already be owned.  If a
// pointer value is not owned, but refers to a value that has a
// refcount of 1, it is called "run-time" owned, and the value
// bytes include the hash of the referred value or object as if
// owned; the value bytes also include the object-id of the
// "run-time" owned object as if it were persisted separately
// from its base object, but implementations may choose to
// inline the serialization of "run-time" owned objects anyway.
// If an object is owned, the value hash of elements is
// included, otherwise, the value hash of elements is not
// included except for objects with refcount=1.  If owned but
// any of the elements are already owned, or if not owned but
// any of the elements have refcount>1, image derivation
// panics.

Logos Browser

Logos is a Gno object browser. The modern browser as well as the modern javascript ecosystem is from a security point of view, completely fucked. The entire paradigm of continuously updating browsers with incrementally added features is a security nightmare.

The Logos browser is based on a new model that is vastly simpler than HTML. The purpose of Logos is to become a fully expressive web API and implementation standard that does most of what HTML and the World Wide Web originally intended to do, but without becoming more complex than necessary.


Initially, we don't need to implement routines because realm package functions provide all the inter-realm functionality we need to implement rich smart contract programming systems. But later, for various reasons including long-running background jobs, and parallel concurrency, Gno will implement deterministic concurrency as well.

Determinism is supported by including a deterministic timestamp with each channel message as well as periodic heartbeat messages even with no sends, so that select/receive operations can behave deterministically even in the presence of multiple channels to select from.


Software projects that don't become complete are projects that are forever vulnerable. One of the requisite goals of the Gno language and related software libraries like Logos is to become finished within a reasonable timeframe.

How to become a Gnome

First, read the license. The license doesn't take away any of your rights, but it gives the Gno project rights to your contributions.

Contributions in the form of completed work in a pull request or issue or comments are welcome and encouraged, especially if you are interested in joining the project.

The biggest bottleneck in these sorts of projects is finding the right people with the right skillset and character; and my highest priority besides coding, is to find the right contributors. If you can grok the complexities of this and related projects without hand holding, and you understand the implications of this project and are aligned with its mission, read on.

The Gno Foundation is a non-profit with missions originally stated in the Virgo Project. The Gno Foundation, which owns the IP to the Gno Works, proposes the following:

  • The Gno Foundation permits the Gnoland chain the usage of the Gno Works.

  • The Gnoland chain's staking token is given equally to three bodies:

    • 1/3 of GNOTs to the Gno Foundation.
    • 1/3 of GNOTs to the Gno Community.
    • 1/3 of GNOTs to an opinionated spoonful of ATOMs.

Spoonful of atoms to be weighted according to voting history, such that those who voted in favor of good proposals and against bad proposals as judged by the Gno Foundation, as well as those who were active in voting, are given favor. The weighting may be such that some ATOM holders receive no GNOTs. This is not a fork of the Cosmos Hub, but a new chain, so the distribution is entirely at the Gno Foundation's discretion, and the foundation has strong opinions.

The Gno Community is determined by the creation and finalization of the project, as determined by the Gno Foundation according to community contributions.

Reading the code

Gno's code has been written with extensive comments that explain what each file does. Eventually, each function will be commented in the same manner.

You can learn a great deal from reading Gnocode, and it's recommended that both users and developers have a look.


If you can read this, the project is evolving (fast) every day. Check "" and @jaekwon frequently.

The best way to reach out right now is to create an issue on github, but this will change soon.

  • GnOS Docker container

    GnOS Docker container

    As I mentioned in my issue with musings, I basically kept going on the path I've been pursiing since about 2015 when I realized that without secure systems to run them on, blockhains mean naught.

    This is a starting point, not a finsishing point.

    Because Arch makes its build system easy to reproduce, we could eventually move all pieces of the build here, so they can be checked alongside the rest of the gno codebase.

    This PR adds the code needed to automatically build (from scratch) amd64/arm64 docker images for gno.

    To ease onboarding, these images can then be used as a developer environment, with preinstalled tooling, and we can adopt a .gitpod.yml file in the repo root that uses this container, allowing people to skip the harsh "omg wut, tooling" stage of onboarding.

    opened by faddat 11
  • feat: support realm subpackages

    feat: support realm subpackages

    Large program (included smart contracts?) has constructed with packages. Like normal packages (, This PR is for realm sub(nested) packages like below.

    ├── integration_test.gno
    ├── package.go
    ├── v1
    │   └── v1.gno
    └── v2
        └── v2.gno

    IMHO, Subpackages can be helpful in the versioned or upgradable realm. For realm's ownership, A creator should be equal to root realm(<root>) and sub realms (<root>/<sub>). So I added PackageAccount.Owner to GnoAccount.

    This is a realm package account

    $ gnokey query auth/accounts/g1pzll2zyn0rrcshefa25k8v50annqr6lew80pq2
    height: 0
    data: {
      "BaseAccount": {
        "address": "g1pzll2zyn0rrcshefa25k8v50annqr6lew80pq2",
        "coins": "",
        "public_key": null,
        "account_number": "76",
        "sequence": "0"
      "PackageAccount": {
        "owner": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5"

    This is an normal account.

    height: 0
    data: {
      "BaseAccount": {
        "address": "g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5",
        "coins": "9999980000000ugnot",
        "public_key": null,
        "account_number": "0",
        "sequence": "0"
    $  gnokey maketx addpkg anarcher --pkgpath "" --pkgdir .  --gas-fee "1ugnot"  --gas-wanted
    "5000000"  --broadcast true
    Enter password.
    GAS WANTED: 5000000
    GAS USED:   356358
    opened by anarcher 8
  • Chat?


    Projects usually have some kind of "hub" chat.

    There are a whole bunch of advantages and disadvantages to each, but if we're going our own way....

    What about a text-based, secure P2P chat designed to run on Raspberry Pi computers for now, and soon, on Minimus machines.

    I think that willingness to run a single board computer (or a VM, or even a native go app on your laptop, I suppose) would be a super-great filter.

    Yeah, we're not on slack/discord.


    Ofc, in the long term, seems like the chat would actually run in gno, with messages being delivered to realms and decrypted with a private key held by users/devs. I think.

    help wanted 
    opened by faddat 8
  • feat: add a Gno2Go precompiler

    feat: add a Gno2Go precompiler

    This PR is a proposal for

    Official target:

    • [x] Rename .go to .gno where appropriate
    • [x] Make gno precompiler (which comes before preprocessor) compile .gno to .go in same folder.
    • [x] "" in .gno becomes "" in .go.
    • [x] "std" becomes "" (?)
    • [x] keeps a whitelist of stdlib packages (to prevent attacks, to prevent compiling malware).
    • [ ] Precompiler tries to compile the translated .go code using go, before proceeding.

    My plan/implementation:

    • [x] implement a transformation system in the gno.Gno2Go func.
    • [x] replace std with
    • [x] replace with
    • [x] always add a top-level comment to indicate that the .go files was generated (in case someone commits the generated files).
    • [x] removed tests/go.mod, no you can safely run go test -v ./... from the top-level directory.
    • [x] because ./stdlibs/* is both used by the .gno files and also by some .go files, I decided to rename them to .gno and create symlinks for each files so that go test ./... can work.
    • [x] initial version of a gnodev tool with gnodev precompile ./path/to/package
    • [ ] bootstrap a simple stdshim package.
    • [ ] way to ensure the go version we're checking against, for distributed determinism. (

    ~Also, I’ve a suggestion: what do about creating a new cmd/gnodev command, dedicated to contract developers, with tools like precompile, test and other developer tools? That’s personally what I would love to work with.~

    Note: the PR is pretty big, because it renames a lot of .go files to .gno; the interesting files here are gno2go{,_test}.go.

    Fixes #107 Related with #121 Closes #113 (replace)

    opened by moul 7
  • feat: add 'gnodev test' command

    feat: add 'gnodev test' command


    gnodev test --help    
    # testOptions options
    - verbose (bool) - verbose 
    - root-dir (string) - clone dir 


    gnodev test ./examples
    ?       ./examples/       [no test files]
    ?       ./examples/      [no test files]
    ?       ./examples/       [no test files]
    ?       ./examples/         [no test files]
    ?       ./examples/    [no test files]
    ?       ./examples/        [no test files]
    ?       ./examples/    [no test files]
    ?       ./examples/     [no test files]
    ok      ./examples/      51.707949ms
    ?       ./examples/  [no test files]
    ?       ./examples/     [no test files]
    ?       ./examples/         [no test files]
    ?       ./examples/      [no test files]
    ?       ./examples/  [no test files]
    ?       ./examples/    [no test files]
    ok      ./examples/     497.964559ms
    ?       ./examples/       [no test files]
    ok      ./examples/  55.550871ms
    ?       ./examples/     [no test files]
    ?       ./examples/         [no test files]
    ?       ./examples/     [no test files]
    opened by moul 6
  • WIP: fixing some nondeterministic tests

    WIP: fixing some nondeterministic tests


    • [x] fix TestTransportMultiplexAcceptNonBlocking
    • [ ] fix TestSignerVoteKeepAlive

    The timeout based tests are definitely a problem. The privval socket system maybe requires a redo, or merging fixes from mainline tendermint at some point. The p2p/transport system is also pretty confusing.

    This PR can stay open while we find more issues.

    opened by jaekwon 6
  • fix: change board of quickstart guide

    fix: change board of quickstart guide

    Change the link of old quick start board to redirect on a board with the up to date one based on the avaliable in examples/

    Fixes #220

    opened by Doozers 5
  • gofumpt


    I've been using gofumpt a lot and really like the regularity that it adds to code.

    You should be able to exactly reproduce this pr like:

    go install gofumpt -w -l .

    and it is probably not advisable to look at every single file but instead diffs.

    gofumpt describes itself as a stricter, go fmt compatible version of go fmt

    PS if it's not desired or useful please feel free to close this PR

    if it is desired/useful, it can be ci enforced if we'd like it to be

    I think Osmosis is going with "once per release"

    opened by faddat 5
  • Makefile + Github Action

    Makefile + Github Action

    • Makefile supports native builds, other platforms require cgo and a tool chain and appropriate environment variables
    • Github Action builds
    • Github Action runs tests
    • Border struct modified to add HasBorder bool
    • Comments added to logos.go
    • Added a Changelog
    • adds mild docs to logos

    closes #9

    opened by faddat 5
  • Makefile


    • Made xgo the default build tool so that contributors don't need to worry about a C environment or cross-compile config
    • Added a basic Makefile
    • Set default build targets to be amd64/arm64 for mac, windows, and linux
    • Made the default darwin version 10.14 for compatibility reasons
    opened by faddat 5
  • Panic call payment must not be less than 200000000\

    Panic call payment must not be less than 200000000\" string when using quotation marks

    I had someone on Discord with constant errors, trying to make a username. He had 7436004650ugnot

    First he tried ./build/gnokey maketx call g1a8a2pxj6jkvkqtph745g3mct2uwnynajxgyaet --pkgpath "" --func "Register" --gas-fee 1000000ugnot --gas-wanted 2000000 --send "" --broadcast true --chainid "test2" --args "" --args "CARPEDIEMWORLD" --args "CARPEDIEMWORLD" --remote "" Got error payment must not be less than 200000000"}}\nMsg Traces:\n--= /Error =--\n,events:[]"}}

    His next try was ./build/gnokey maketx call g1a8a2pxj6jkvkqtph745g3mct2uwnynajxgyaet --pkgpath "" --func "Register" --gas-fee 1000000ugnot --gas-wanted 2000000 --send "200000000ugnot" --broadcast true --chainid "test2" --args "" --args "CARPEDIEMWORLD" --args "CARPEDIEMWORLD" --remote "" Got error transaction failed &core_types.ResultBroadcastTxCommit{CheckTx:abci.ResponseCheckTx{ResponseBase:abci.ResponseBase{Error:std.InvalidGasWantedError{abciError:std.abciError{}}, Data:[]uint8(nil), Events:[]abci.Event(nil), Log:"--= Error =--\nData: std.InvalidGasWantedError{abciError:std.abciError{}}\nMsg Traces:\n 0 /opt/build/pkgs/std/errors.go:102 - invalid gas-wanted; got: 200000000 block-max-gas: 10000000\nStack Trace:\n 0 /opt/build/pkgs/errors/errors.go:20\n 1 /opt/build/pkgs/std/errors.go:102\n

    First option I gave him was ./build/gnokey maketx call ADDRESS --pkgpath "" --func "Register" --gas-fee 1000000ugnot --gas-wanted 2000000 --send "2000000ugnot" --args "" --args "NAME" --args "" > unsigned.tx (NAME in lower case)

    ./build/gnokey sign ADRRESS --txpath unsigned.tx --chainid test2 --number ACCOUNT --sequence NUMBER > signed.tx
    ./build/gnokey broadcast signed.tx --remote ""

    He got error tException:\n\t (\"payment must not be less than 200000000\" string)\n\t payment must not be less than 200000000"}}\nMsg Traces:\n--= /Error =--\n,events:[]"}}

    I than asked for screenshot screenshot-errors I remember people had problems before when using quotation marks but they gave different errors. I told him to try

    ./build/gnokey maketx call g1a8a2pxj6jkvkqtph745g3mct2uwnynajxgyaet --pkgpath "" --func "Register" --gas-fee 2000000ugnot --gas-wanted 2000000 --send 200000000ugnot --broadcast true --chainid test2 --args "" --args "carpediemworld" --args "" --remote

    And it worked screenshot-final-result

    I don't know if this might give problems in the future but I want to let you know.

    I don't know if it's been reported yet but there's also problems when

    --gas-fee 1gnot is used, it needs to be --gas-fee 1000000ugnot or people get a insufficient funds to pay for fees; 2100000000ugnot < 1gnot error, or whatever they have, on any realm being called.

    opened by KorNatten 4
  • WIP: refactor AVL

    WIP: refactor AVL

    This PR makes AVL more intuitive to use.

    • Tree -> Node; MuTTree -> Tree. // Usually there is something called a "node".
    • An empty Tree struct can be used as zero, as long as it is addressable/modifiable.
    • Replaced usage of Node with Tree in demo/boards.
    opened by jaekwon 1
  • Fix: file tests should have failed in Github CI. Added sync flag to sync the wanted and actual results for local testing

    Fix: file tests should have failed in Github CI. Added sync flag to sync the wanted and actual results for local testing


    #440 3 of 3

    This commit is the last step to fixing the false testing result during Github CI We keep the feature to sync the actual output to test comments in files. It allowed us to see wanted outcomes overwritten by actual results during local testing. "Git status" shows modified testing files.

    1. Added a syncWanted parameter to the RunFileTest() in tests/file.go and runFileTest() in tests/file_test.go. It makes the function contract clear without relying upon the side effect of the syncWanted variable while we still maintain the custom testing flag available in file_test.go for the Makefile to execute in CI.

    2. Set package variable syncWanted as a golang custom testing flag --sync in tests/file_test.go. The default value is false. It allows the CI to stop at failure cases when executing file tests in the tests/files and tests/files2 folder

    3. Added --sync flog in cmd/gnodev/test.go. The default value is false. It allows CI to stop at failure cases when executing file tests in ./examples

    4. Added three entries in the Makefile. It allows us to turn on the sync flag during the local testing test.files1.sync test.files2.sync test.examples.sync

    5. To run tests/files and tests/files2 file test with sync on

      go test ./tests -v --sync
    6. To run file test in ./examples with sync on

      ./build/gnodev test ./examples --sync

    How has this been tested?

    1. Modify the realm hash in

      tests/files/zrealm_example.gno tests/files2/zrealm_example.gno

      make test.files1 - failed make test.files2 - failed

      make test.files1.sync - passed make test.files2.sync - passed

      The correct hash value was written back to the file test comments.

    2. Replaced print with println in examples/

      make test.examples - failed

      make test.examples.sync - passed

      The correct rendering output was written back to the file test comments.

    opened by piux2 0
  • WIP: r/demo/boards pagination

    WIP: r/demo/boards pagination

    Investigating approach to use for pagination. The current draft form works for next-pagination but doesn't really help skip forward or go backward. So I'll be replacing "last" with offset, and make sure avl iteration can support offsets.

    opened by jaekwon 3
  • [repl] preserve state between lines; allow decls.

    [repl] preserve state between lines; allow decls.

    1. Right now the repl doesn't seem to remember any state between lines, so you have to enter all the lines in one go: var a = 1; print(a);.
    2. Also, the only lines allowed are statements, but not declarations, so no imports are allowed.

    I think we want to fix (1) first, then (2) work on allowing also declarations (if not a statement; order probably significant to prefer Decl over DeclStmt?) interspersed with regular statements; to make the repl actually useful. (also note: SimpleDeclStmt should not be used or modified for this purpose; rather the REPL is doing the work to conform to existing gno code). Then one could type in the repl:

    > import fmt
    > a := "hello"
    > fmt.Println(a)

    That said, the repl doesn't seem to be high priority.

    opened by jaekwon 1
  • PoC: `VMKeeper.QueryEvalJSON`

    PoC: `VMKeeper.QueryEvalJSON`


    Render is an interesting feature in gno. But IMHO, Query with json would be nice to programmatically interact.

    package hello
    type User struct {
            ID   int    `json:"id"`
            Name string `json:"name"`
    func Hello() *User {
            return &User{ID: 1, Name: "hello"}
    $ gnokey query "vm/qeval" --data "
    height: 0
    data: {"id":1,"name":"hello"}

    I'm not sure that this approach is suitable or not in gno. and it`s not yet an accurate, performant json encoder for now. it's just POC. What do you think about this approach? :-)

    How has this been tested?


    opened by anarcher 0
A simple implementation of SHA-256 Algorith in Go Language

SHA-256 in Go This is not a serious/efficient implementation of SHA-256 in Go. You can use the official package for that. This is just for learning pu

Krona Emmanuel 6 Sep 22, 2022
Go language implementation of a blockchain based on the BDLS BFT protocol. The implementation was adapted from Ethereum and Sperax implementation

BDLS protocol based PoS Blockchain Most functionalities of this client is similar to the Ethereum golang implementation. If you do not find your quest

Yongge Wang 1 Oct 14, 2022
This library aims to make it easier to interact with Ethereum through de Go programming language by adding a layer of abstraction through a new client on top of the go-ethereum library.

Simple ethereum client Simple ethereum client aims to make it easier for the developers to interact with Ethereum through a new layer of abstraction t

Jero 3 May 1, 2022
This is the repository I made while learning Go Programming Language & You can follow this repository to learn it

Golang Arena ?? Hey Folks! Welcome to Golang Arena . This is the repository I made while learning Go Programming Language & You can follow this reposi

Anukul Pandey 1 Jan 31, 2022
Generate code for any language, with any language.

gocog - generate code for any language, with any language gocog v1.0 build 20130206 Binaries for popular OSes are available on the Downloads page of t

Nate Finch 66 Aug 5, 2022
Floppa programming language inspired by the brainf*ck programming language. Created just for fun and you can convert your brainf*ck code to floppa code.

Floppa Programming Language Created just for fun. But if you want to contribute, why not? Floppa p.l. inspired by the brainf*ck programming language.

null 19 Oct 20, 2022
Please is a cross-language high-performance extensible build system for reproducible multi-language builds.

Please is a cross-language build system with an emphasis on high performance, extensibility and reproducibility. It supports a number of popular languages and can automate nearly any aspect of your build process.

Thought Machine 2.2k Dec 30, 2022
Q Language : A script language for Go

Q Language - A script language for Go 语言特色 与 Go 语言有最好的互操作性。可不进行任何包装即可直接使用 Go 语言的函数、类及其成员变量和方法。 有赖于 Go 语言的互操作性,这门语言直接拥有了一套非常完整且您十分熟悉的标准库,无额外学习成本。 与 Go

null 13 Sep 5, 2022
T# Programming Language. Something like Porth, Forth but written in Go. Stack-oriented programming language.


T# 92 Jun 29, 2022
A repository for showcasing my knowledge of the Google Go (2009) programming language, and continuing to learn the language.

Learning Google Golang (programming language) Not to be confused with the Go! programming language by Francis McCabe I don't know very much about the

Sean P. Myrick V19.1.7.2 2 Nov 6, 2022
A repository for showcasing my knowledge of the Go! (2003) programming language, and continuing to learn the language.

Learning Go! (programming language) Not to be confused with Google Golang (2009) I don't know too much about the Go! programming language, but I know

Sean P. Myrick V19.1.7.2 2 Oct 22, 2022
Yayx programming language is begginer friendly programming language.

Yayx Yayx programming language is begginer friendly programming language. What have yayx: Easy syntax Dynamic types Can be compiled to outhers program

null 1 Dec 27, 2021
Yayx programming language is begginer friendly programming language.

Yayx Yayx programming language is begginer friendly programming language. What have yayx: Easy syntax Dynamic types Can be compiled to outhers program

Yayx Programming Language 7 May 20, 2022
Becca - A simple dynamic language for exploring language design

Becca A simple dynamic language for exploring language design What is Becca Becc

Nicholas Bailey 1 Aug 15, 2022
Tdtl - TKeel Digital Twins Language (TDTL) is language of Digital Twins in tKeel

TQL TKeel Digital Twins Language (TDTL) is language of Digital Twins in tKeel, w

null 1 Feb 18, 2022
go language generics system

Gotgo This document describes the third iteration of my attempt at a reasonable implementation of generics for go based on the idea of template packag

David Roundy 119 Dec 4, 2021
AWS SDK for the Go programming language.

AWS SDK for Go aws-sdk-go is the official AWS SDK for the Go programming language. Checkout our release notes for information about the latest bug fix

Amazon Web Services 8.1k Jan 1, 2023
Go language interface to Swift / Openstack Object Storage / Rackspace cloud files (golang)

Swift This package provides an easy to use library for interfacing with Swift / Openstack Object Storage / Rackspace cloud files from the Go Language

Nick Craig-Wood 294 Nov 9, 2022
pongo2 is a Django-syntax like templating-language

Django-syntax like template-engine for Go

Florian Schlachter 2.4k Dec 27, 2022
A simple set type for the Go language. Trusted by Docker, 1Password, Ethereum and Hashicorp.

golang-set The missing set collection for the Go language. Until Go has sets built-in...use this. Coming from Python one of the things I miss is the s

Ralph Caraveo III 2.9k Jan 8, 2023