Tom's Obvious, Minimal Language

Related tags

Configuration toml

TOML logo


Tom's Obvious, Minimal Language.

By Tom Preston-Werner, Pradyun Gedam, et al.

This repository contains the in-development version of the TOML specification. You can find the released versions at


TOML aims to be a minimal configuration file format that's easy to read due to obvious semantics. TOML is designed to map unambiguously to a hash table. TOML should be easy to parse into data structures in a wide variety of languages.


# This is a TOML document.

title = "TOML Example"

name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00 # First class dates

server = ""
ports = [ 8000, 8001, 8002 ]
connection_max = 5000
enabled = true


  # Indentation (tabs and/or spaces) is allowed but not required
  ip = ""
  dc = "eqdc10"

  ip = ""
  dc = "eqdc10"

data = [ ["gamma", "delta"], [1, 2] ]

# Line breaks are OK when inside arrays
hosts = [

Comparison with Other Formats

TOML shares traits with other file formats used for application configuration and data serialization, such as YAML and JSON. TOML and JSON both are simple and use ubiquitous data types, making them easy to code for or parse with machines. TOML and YAML both emphasize human readability features, like comments that make it easier to understand the purpose of a given line. TOML differs in combining these, allowing comments (unlike JSON) but preserving simplicity (unlike YAML).

Because TOML is explicitly intended as a configuration file format, parsing it is easy, but it is not intended for serializing arbitrary data structures. TOML always has a hash table at the top level of the file, which can easily have data nested inside its keys, but it doesn't permit top-level arrays or floats, so it cannot directly serialize some data. There is also no standard identifying the start or end of a TOML file, which can complicate sending it through a stream. These details must be negotiated on the application layer.

INI files are frequently compared to TOML for their similarities in syntax and use as configuration files. However, there is no standardized format for INI and they do not gracefully handle more than one or two levels of nesting.

Further reading:

Get Involved

Documentation, bug reports, pull requests, and all other contributions are welcome!


We have an Official TOML Wiki that catalogs the following:

  • Projects using TOML
  • Implementations
  • Validators
  • Language-agnostic test suite for TOML decoders and encoders
  • Editor support
  • Encoders
  • Converters

Please take a look if you'd like to view or add to that list. Thanks for being a part of the TOML community!

  • Proposal: Reference shortcut for nesting tables

    Proposal: Reference shortcut for nesting tables

    Consider the following exampe:

      ip = ""
      dc = "eqdc10"
      ip = ""
      dc = "eqdc10"

    Idea: add a shortcut character to reference the outer table.


      ip = ""
      dc = "eqdc10"
      ip = ""
      dc = "eqdc10"

    The character # is illustrative and may have to be reconsidered giving it's used already for comments.

    The proposal also considers multiple levels:

      ip = ""
      dc = "eqdc10"
    inbound = "" # this would become `servers.alpha.firewall.inbound`
    outbound = "" # similarly, `servers.alpha.firewall.outbount`
      ip = ""
      dc = "eqdc10"

    The multi-level indicator, e.g. #.#.#..., must match the current structure. For example, right below a single-level table [bar] must be considered invalid. IDEs and plugins for text editors should be able to provide tooltip to indicate the expanded name of the referenced tables, expanding the value.

    The benefit of this feature is to simplify typing while keeping explicitly defined the level of the table, and also in reducing the chances of typos when nesting tables. Can also facilitate when copying/pasting snippets.

    opened by brunoborges 92
  • Allow keys in key-value pairs to be paths

    Allow keys in key-value pairs to be paths

    The only remaining idea from #292 that has not been decided upon and does not have a dedicated issue.

    I mean, I don't know how much I like it myself but, hey, this needs discussion so, here's a dedicated issue for it.

    title = "Hello!"
    meta.charset = "utf-8"
    opened by pradyunsg 86
  • Revisit array of table syntax

    Revisit array of table syntax

    I found the type "array of table" not especially easy to grasp in TOML. This is because the syntax of an array of table is different from an array of, say, integer. It is not the case in JSON. So while I found TOML clearer than JSON regarding table, I found JSON easier to understand regarding array of table.

    In the end, I was wondering if the type "array of table" was absolutely necessary in a config file. My point is that the way the data are stored (table of table vs. array of table) might be of low interest for the end-user that just want to modify some parameters.

    I understand that, compared to "table of table", "array of table" has:

    • ordered elements
    • unnamed elements.

    Among actual TOML usage, is there a situation where "array of table" is much more efficient than "table of table" ?

    To be a little more specific, here are the comparison of both syntax (not exactly similar of course): Array of table:

        name = "Hammer"
        sku = 738594937
        name = "Nail"
        sku = 284758393

    Table of table:

        name = "Hammer"
        sku = 738594937
        name = "Nail"
        sku = 284758393
        color = "gray"

    IMO, the advantage of using table of table only are:

    • a unique syntax (less confusing)
    • each table has a name (less need of referring to the manual)

    My question is certainly not if it is relevant to remove the array of table from the specs, but to see if a best practice could encourage to avoid array of table against table of table.

    opened by maxhaz 75
  • Adds multi-line string to spec.

    Adds multi-line string to spec.

    I think there should be some kind of baked-in support for multi-line strings, especially since that's the primary reason (IMO) that JSON sucks as a specification language. Here I'm adding the CoffeeScript style triple-quotes but I'm fine with anything, really.

    opened by mbleigh 75
  • range type

    range type

    I'm new to TOML and really liking it. The one thing I'd really find helpful is a range type, which implementations could interpret either as a range object (e.g., Python) or as an explicit array, depending on the language. I anticipate "just use a 3-array" or "just provide start, stop, and step attributes" as responses, but if you search you'll find that YAML and JSON users also request ranges from time to time. So I think there is a desirable feature here. I'm not going to suggest syntax but array syntax without commas [0 10 1] or doubled periods 0..10..1 or even Mathematica span style 0;;10;;1 pop into mind.

    opened by alan-isaac 67
  • Support single-quoted strings to avoid double \

    Support single-quoted strings to avoid double \

    The example for TOML shows how bad it gets when writing a Windows path that has , unfortunately some things that get configured need to let a user enter a regular expression. Regular expressions are filled with back-slashes, and adding the extra backslash constantly is very painful.

    To give TOML a fighting chance when someone might need to use a few backslashes in a config file, I propose using single quotes to designate a raw string, ie:

    somevar = 'this is a \d+ \w+ type of string'

    This would retain the existing double-quote rules to avoid breaking existing usage.

    opened by bbangert 64
  • Allow non-English scripts for unquoted keys

    Allow non-English scripts for unquoted keys

    Fixes: #687

    Support all international scripts, except for certain non-symbols, arrows and joins. This PR largely follows the recommendation in my comment (, except where that conflicted with backward compat issues (i.e., we allow keys to start with a digit or dash, and that should stay that way).

    The excluded ranges are mostly those that are really not "letterlike" (arrows, line drawing chars, spaces, punctuation). If someone feels that some of the excluded ranges should be included, by all means, let me know.

    ABNF verified with

    Here are some examples that will work once this is allowed. Tested with

    # Examples that are now valid unquoted keys
    zeeën = "'seas' - Dutch"
    Cuántos-años = "'How old' - Spanish"
    الساعة = "arabic"
    汉语大字典 = "cjk ideographs"
    辭源 = "Ciyuan"
    பெண்டிரேம் = "'we are women' - in Tamil"
    गंगा = "'Ganges' - in Devanagari, Hindi"
    העברית = "'Academy' - Hebrew"
    Тіні-забутих-предків = "'Shadows of forgotten ancestors' - movie title in Ukrainian"
    VäinöLinna = "finnish author"
    బడికి = "'School' - in Telugu"
    Người = "'person' - Vietnamese"
    😂 = "x1F602 - smiley"
    ᚠ = "'Cattle' - Rune"
    𓆣𓆤𓆥𓆦 = "Egyptian hieroglyphs"
    Fuß = "'Foot' - German"
    français  = "'French' - French"
    # These are still valid
    - = "single dash"
    3 = "digit"
    _ = "underscore"
    opened by abelbraaksma 56
  • Allow

    Allow "[]" to return to global scope (for adding sibling array after a table)

    I'm trying to model this Rust struct in TOML:

    #[derive(Debug, Clone, PartialEq, Deserialize)]
    pub struct WhitelistConfig<T: DeviceIdentifier> {
        appliance: Appliance,
        rules: Vec<Rule>,
        ignore: PhantomData<T>

    When writing it out in TOML, I believe the natural way to read/write it would be:

    1. Provide information about the appliance this config file connects to
    2. Provide the list of rules (which could be long)

    That would look something like...

    host = "teddriggs-dev"
    api_key = "MY-API-KEY"
    # this isn't valid right now; it will consider the field to be part of `appliance`
    rules = [
        { tag = "whitelist" },
        { group_id = 1 }

    One approach I thought of that could address this would be allowing [] to appear once to return to global scope after entering a table. It would be invalid to use [] if the document started with key-value pairs, avoiding the splitting of a table definition.

    This might be too narrow a case, but I think the pattern of 'metadata + a list' seems likely to occur somewhat frequently. This may also dovetail with #309; shorter syntax for arrays-of-tables would make me less concerned about teaching users the [[rules]] construct.

    opened by TedDriggs 52
  • Tuples and Inline Tables: A Motivation

    Tuples and Inline Tables: A Motivation

    This builds on, which would be very useful regardless of whether this proposal is accepted.

    Hurray for tuples! @mojombo

    Currently, there is no syntax for inline tables, which means that you're forced to create a new section for simple cases. In Cargo:

    version = "1.0.0"
    git = ""

    We have a shorthand for the case where a dependency only needs to specify a version:

    hammer = "1.0.0"

    With tuples, we could do something like:

    hammer = ("1.0.0", "git", "")

    I would like to propose a syntax for inline tables:

    hammer = ("1.0.0", git: "")
    # or alternately
    hammer = ("1.0.0", git = "")

    I would be comfortable with restricting inline tables to the last element of a tuple, to eliminate the need for additional braces or something around the table.

    opened by wycats 51
  • Add inline table syntax.

    Add inline table syntax.

    Concrete proposal for the inline table syntax I first proposed in Issue #219. Here's a quick taste:

    # They should look familiar and obvious
    name = { first = "Tom", last = "Preston-Werner" }
    point = { x = 1, y = 2 }
    # They make tuples unnecessary by allowing mixed types (they are just tables, after all).
    # Unlike tuples, they are self-documenting via the key names.
    address = { proto = "http", ip = "", port = 8080 }
    # Arrays of tables with less hassle
    points = [ { x = 1, y = 2, z = 3 },
               { x = 7, y = 8, z = 9 },
               { x = 2, y = 4, z = 8 } ]

    This is about as brief as I could think to make it, so if there are specific issues that need clarifying, please bring them up.

    opened by mojombo 49
  • The spec language seems to forbid writing to the same defined table using dotted keys

    The spec language seems to forbid writing to the same defined table using dotted keys

    (I may have made some mistakes in this write-up, but I hope I have made the contradiction obvious by the time you get to the end. Please read to the end, because I may be identifying multiple problems, so if you feel I am wrong about one issue you should still consider the rest of this write-up.)

    Let's start here:

    Dotted keys define everything to the left of each dot as a table. Since tables cannot be defined more than once, redefining such tables using a [table] header is not allowed. Likewise, using dotted keys to redefine tables already defined in [table] form is not allowed.

    The contradiction is here:

    1. Dotted keys define everything to the left of each dot as a table.
    2. tables cannot be defined more than once

    Here, "define" must mean explicitly defined (because tables can be implicitly defined multiple times by either dotted keys or headers) and no delineation is made between tables "defined in dotted keys" versus tables defined in headers (referred to elsewhere in the spec as "directly defined"). It is stated that any table (explicitly) "defined" cannot be (explicitly) "defined" again. That means this should be invalid:

    apple.color = "red" # Here, apple is "defined as a table"
    apple.taste.sweet = true # Here apple is "defined" AGAIN as a table

    I would also add that the spec should explicitly state that "dotted keys" can NOT refer to keys separated by dots inside headers. Otherwise, that would also mean that defining headers out of order would be invalid.

    # `fruit` is implicitly defined as a table
    # `apple` is explicitly defined as a table within `fruit`
    # fruit is explicitly defined as a table
    # of course, this document should be valid!

    Now, if you interpret "define" as implicitly defined in this case, that still doesn't work. More on this later.

    We see the following elsewhere in the spec:

    As long as a key hasn't been directly defined, you may still write to it and to names within it.

    # This makes the key "fruit" into a table. = true
    # So then you can add to the table "fruit" like so: = 2

    The above is the only place in the spec where the term "directly defined" is used to delineate between the different kinds of "define". (Aside from where it says that in-line tables are "fully defined" at their location and cannot be added to or modified, but that is pretty air-tight so I don't want to focus on it at all.)

    The (first) paragraph in question is followed by "The [table] form can, however, be used to define sub-tables within tables defined via dotted keys." I don't appreciate how the first two examples follow naturally from the principle "Since tables cannot be defined more than once" but the third example is a contradiction of the principle. It's fine for all three of these examples to be fine in TOML, but not without delineating between the different kinds of "define".

    The contradiction leads me to question whether the following is an example of a valid contradiction of the aforementioned principle:

    Is it valid for "dotted keys" (not in headers) to modify something implicitly defined as a table in a header? My guess is yes, since if you change the order it is valid.

    # `fruit` is implicitly defined as a table
    # `apple` is implicitly defined as a table in `fruit`
    # `taste` is explicitly defined as a table in `apple`
    # fruit is explicitly defined as a table
    apple.color = "red"
    # apple is (indirectly) defined as a table with color set to "red"

    While there are occurrences in the spec where you can easily infer the difference between the kinds of "define" being used (including in some examples above), the top quotation seems to imply it is possible to possible to implement the "dotted keys" by only delineating between defined tables and implicitly defined tables (leaving aside arrays and in-line tables for now), when in fact, it is not possible. You HAVE TO delineate between dotted key definitions (not in headers) versus header definitions. There is no way to satisfy all the rules any other way.

    Here is an example of an implementation. It's a bit TypeScripty, hopefully others can understand what I am getting at.

    Define enum ScopeType as having members: { Inferred, Defined } Define scopeTypes as a Map/Hash of Table -> ScopeType. Let global be the global scope

    A Map pairs keys with values, and has methods "has", "get" and "set". "has" returns whether a mapping exists for a given key. "get" returns what a given key maps to. "set" maps a given key to a given value. In this case, ScopeTypes.has(value) is another way of expressing that a given value is not a literally defined value, e.g.1 or false
    # assert global["a"] == undefined or scopeTypes.get(global["a"]) == ScopeType::Inferred
    # define `a` as global["a"] or an empty table {}
    # scopeTypes.set(a, ScopeType::Defined)
    b.c = 1
    # assert a["b"] == undefined or scopeTypes.has(a["b"])
    # scopeTypes.set(b, ScopeType::Inferred)
    [a.b] # should be forbidden
    # assert global["a"] == undefined or scopeTypes.has(global["a"])
    # define `a` as global["a"] or an empty table {}
    # scopeTypes.set(a, ScopeType::Inferred)
    # assert a["b"] == undefined or scopeTypes.get(a["b"]) == ScopeType::Inferred
    # define `b` as a["b"] or an empty table {}
    # scopeTypes.set(b, ScopeType::Defined)

    The crux of the problem here is in our [a.b] logic, where b may only be Inferred, in order to allow these cases:

    # `a` is Inferred
    # `b` was Inferred, but is now Defined
    [a.b] # `a` is Defined
    # `b` was undefined, is now Defined

    And block this case:

    # b is defined
    # b is defined already! error!

    Hence, there is no way to block "redefining such tables [tables defined by dotted keys] using a [table] header is not allowed." E.g.

    b.c = 1
    [a.b] # forbidden?
    # `a` is Inferred
    # b is must be Defined in order to block this

    So let's rewrite our logic where we set b in b.c = 1 to be Defined in order to account for the above case:

    a.b = 1
    # assert global["a"] == undefined or scopeTypes.get(global["a"]) == Defined
    # define `a` as global["a"] or empty table {}
    # scopeTypes.set(a, ScopeType::Defined)
    # set a["b"] = 1

    Now we can't block this:

    # fruit is Inferred
    # apple is Defined
    # fruit is Defined
    apple.color = "red" # This is acceptable by the above logic
    # To block this, we'd need to assert `apple` is not Defined

    There is no way to block the above document without blocking the use of the same dotted-key-defined-table using only 2 ScopeType enums.

    a.b = 1
    # `a` is Defined here
    a.c = 2
    # We must allow `a` to be Defined for this
    # But if we allow `a` to be Defined, we can't block the previous case!

    I am trying to get the point across using code here because I don't know of a better way to express this technically. We need to delineate between dotted key define's versus header define's in the spec in order for it to make logical sense.

    (I may have made some mistakes in this write-up, but I hope I have made the contradiction obvious by the time you've managed to read this far.)

    opened by Validark 47
  • Clarify which control characters are allowed in comments

    Clarify which control characters are allowed in comments

    Currently the spec says this:

    Control characters other than tab (U+0000 to U+0008, U+000A to U+001F, U+007F) are not permitted in comments.

    However there are more control codes than just those listed in parentheses - namely the ones listed above cover the C0 control code range, but there are also the C1 control codes (U+0080 to U+009F), which are valid unicode. It is unclear from the specification whether the C1 codes are allowed to be present in comments or not.

    opened by autumnull 1
  • Clarify Unicode and UTF-8 references

    Clarify Unicode and UTF-8 references

    This PR applies the changes to clarify Unicode and UTF-8 references, done originally for #924 while considering relaxations on control code in comments. These are standalone changes, separate from the original scope of #924. Many thanks to @abelbraaksma and @ChristianSi for their work on this.

    opened by eksortso 2
  • Relax comment parsing, per discussion on #567

    Relax comment parsing, per discussion on #567

    In reconsideration of the limitation of control codes within comments discussed in #567, a case was made to simplify comment parsing. This PR intends to replace those previously imposed restrictions with a simplified approach that permits anything except newlines.

    opened by eksortso 45
  • Add Filesize

    Add Filesize

    It would be nice to have Filesizes in TOML.

    test = 1MB # Results in 1.000 * 1.000 = 1.000.000
    test2 = 1MiB # Results in 1.024 * 1.024 = 1.048.576

    Things like max Filesize etc. are used in many configurations and it should be easy to implement for the different parsers.

    opened by JakobDev 6
  • 1.0.0(Jan 12, 2021)

    About time TOML hit 1.0.0!

    • Clarify how tables are created and defined.
    • Clarify and describe the top-level table.
    • Clarify that indentation before keys is ignored.
    • Clarify that indentation before table headers is ignored.
    • Clarify that indentation between array values is ignored.
    Source code(tar.gz)
    Source code(zip)
  • 1.0.0-rc.3(Oct 7, 2020)

    • Clarify that comments and newlines are allowed before commas in arrays.
    • Mark the ABNF as canonical, and reference it from the text specification.
    Source code(tar.gz)
    Source code(zip)
  • 1.0.0-rc.2(Aug 9, 2020)

    • Create as the new primary location to read the TOML spec.
    • Clarify meaning of "quotation marks".
    • Clarify meaning of "expected" value ranges.
    • Clarify that EOF is allowed after key/value pair.
    • Clarify that the various styles for writing keys are equivalent.
    • Clarify that line-ending backslashes must be unescaped in multi-line strings.
    • Add examples for invalid float values.
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-rc.1(Apr 3, 2020)

    • Clarify in ABNF how quotes in multi-line basic and multi-line literal strings are allowed to be used.
    • Leading zeroes in exponent parts of floats are permitted.
    • Clarify that control characters are not permitted in comments.
    • Clarify behavior of tables defined implicitly by dotted keys.
    • Clarify that inline tables are immutable.
    • Clarify that trailing commas are not allowed in inline tables.
    • Clarify in ABNF that UTF-16 surrogate code points (U+D800 - U+DFFF) are not allowed in strings or comments.
    • Allow raw tab characters in basic strings and multi-line basic strings.
    • Allow heterogenous values in arrays.
    Source code(tar.gz)
    Source code(zip)
  • v0.5.0(Jul 10, 2018)

    • Add dotted keys.
    • Add hex, octal, and binary integer formats.
    • Add special float values (inf, nan)
    • Rename Datetime to Offset Date-Time.
    • Add Local Date-Time.
    • Add Local Date.
    • Add Local Time.
    • Add ABNF specification.
    • Allow space (instead of T) to separate date and time in Date-Time.
    • Allow accidental whitespace between backslash and newline in the line continuation operator in multi-line basic strings.
    • Specify that the standard file extension is .toml.
    • Specify that MIME type is application/toml
    • Clarify that U+007F is an escape character.
    • Clarify that keys are always strings.
    • Clarify that you cannot use array-of-table to append to a static array.
    • Clarify that a TOML file must be a valid UTF-8 document.
    • Clarify valid Array values.
    • Clarify that literal strings can be table keys.
    • Clarify that at least millisecond precision expected for Date-Time and Time.
    • Clarify that comments are OK in multiline arrays.
    • Clarify that +0, -0, +0.0, and -0.0 are valid and what they mean.
    • TOML has a logo!
    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Feb 12, 2015)

    • Add Inline Table syntax.
    • Allow underscores in numbers.
    • Remove forward slash as an escapable character.
    • Unicode escapes must be scalar values.
    • Newline is now defined as LF or CRLF.
    Source code(tar.gz)
    Source code(zip)
  • v0.3.0(Nov 10, 2014)

    • Add scientific notation for floats.
    • Allow optional + prefix on integers.
    • Switch to RFC 3339 for datetimes (allowing offsets and fractional seconds).
    • Add multiline and literal strings.
    • Clarify what characters valid keys can contain.
    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Sep 24, 2013)

  • v0.1.0(Mar 17, 2013)

Tom's Obvious, Minimal Language (and friends)
YAML support for the Go language.

YAML support for the Go language Introduction The yaml package enables Go programs to comfortably encode and decode YAML values. It was developed with

null 6.1k Jan 8, 2023
HCL is the HashiCorp configuration language.

HCL HCL is a toolkit for creating structured configuration languages that are both human- and machine-friendly, for use with command-line tools. Altho

HashiCorp 4.5k Jan 9, 2023
Go library for the TOML language

go-toml Go library for the TOML format. This library supports TOML version v1.0.0-rc.3 Features Go-toml provides the following features for using data

Thomas Pelletier 1.4k Dec 27, 2022
Graph-based Declarative Configuration Language

Virgo Configuration Language Most configuration problems reduce to graphs, e.g. Dockerfiles and Makefiles But there are no graph-based configuration l

Matt Rickard 114 Nov 26, 2022
YAML support for the Go language

YAML support for the Go language

Masaaki Goshima 798 Dec 31, 2022
⛳ A minimal programming language inspired by Ink, JavaScript, and Python.

⛳ Golfcart My blog post: Creating the Golfcart Programming Language Getting Started Scope Rules Usage Building and tests Contributions License Golfcar

Andrew Healey 26 Sep 6, 2022
Gec is a minimal stack-based programming language

Gec is a minimal stack-based programming language

aiocat 2 Sep 18, 2022
Gopherscript is a secure and minimal scripting language written in Go.

Gopherscript Gopherscript is a secure scripting/configuration language written in Go. It features a fined-grain permission system and enforces a stron

Debloat 20 Oct 2, 2022
A minimal framework to build web apps; with handler chaining, middleware support; and most of all standard library compliant HTTP handlers(i.e. http.HandlerFunc).

WebGo v4.1.3 WebGo is a minimalistic framework for Go to build web applications (server side) with zero 3rd party dependencies. Unlike full-fledged fr

Kamaleshwar 266 Jan 1, 2023
Minimal and Beautiful Go testing framework

Goblin A Mocha like BDD testing framework written in Go that requires no additional dependencies. Requires no extensive documentation nor complicated

null 869 Dec 25, 2022
Minimal cgo bindings for libenca

enca This is a minimal cgo bindings for libenca. If you need to detect the language of a string you can use guesslanguage package. Supported Go versio

Nikita Vershinin 13 Nov 6, 2022
Minict is a minimal container runtime written in Go.

Minict Minict is a minimal container runtime written in Go. It was made mainly for learning purposes and is intended to be as simple as possible.

null 160 Oct 31, 2022
Minimal UART client in Golang that dumps LPC1343 chips that are locked at CRP1.

Howdy y'all, This is a quick and dirty client for the UART bootloader of the LPC1343, and probably other bootloaders in that chip family. This client

Travis Goodspeed 13 Dec 2, 2022
Minimal and idiomatic WebSocket library for Go

websocket websocket is a minimal and idiomatic WebSocket library for Go. Install go get Highlights Minimal and idiomatic API First

Anmol Sethi 2.5k Dec 30, 2022
Minimal structured logging library for Go

slog slog is a minimal structured logging library for Go. Install go get Features Minimal API First class context.Context support First c

Coder 255 Dec 29, 2022
Minimal and idiomatic WebSocket library for Go

websocket websocket is a minimal and idiomatic WebSocket library for Go. Install go get Highlights Minimal and idiomatic API First

Anmol Sethi 2.5k Dec 31, 2022
❄️ Elsa is a minimal, fast and secure runtime for JavaScript and TypeScript written in Go

Elsa Elsa is a minimal, fast and secure runtime for JavaScript and TypeScript written in Go, leveraging the power from QuickJS. Features URL based imp

Elsa 2.7k Jan 7, 2023
Minimal HTTP File Server for pentesting written in Go

Golang implementation of simple HTTP server with upload feature.

Vincent Carlos 77 Aug 4, 2022
Super minimal, rock-solid foundation for concurrent GUI in Go.

faiface/gui Super minimal, rock-solid foundation for concurrent GUI in Go. Installation go get -u Currently uses GLFW under th

Michal Štrba 459 Dec 23, 2022
A minimal and extensible structured logger

⚠️ PRE-RELEASE ⚠️ DO NOT IMPORT THIS MODULE YOUR PROJECT WILL BREAK package log package log provides a minimal interface for structured logging in ser

Go kit 135 Jan 7, 2023