I'm Phil:

Emitting LLVM-IR intermediate-representation language: experimentations & explorations

inspired by the work on gogen-dump , a more carefully designed, generalized and principled Go code-gen framework

how to beat JSON / gRPC / ProtoBufs in all-Go homogenous envs: code-gen for low-level = high-performance, reflect -less, unsafe -powered (arbitrarily-deep + arbitrarily-indirected) binary (de)serialization

state-transition machines / byte-code VMs + graph-reducing evaluators: P-code machine, Brainf_ck evaluator, template instantiation machine, classical G-machine, spineless-tagless G-machine

self-contained REPL for a mini-language (nums & arithmetic operators) with pluggable interpreters, written from scratch on a Sunday

Full refactoring of my earlier, now years-old legacy go-util packages: general-purpose utility programming libraries I was missing in vanilla Go

(Dec 2017 - Oct 2018) on-site in Düsseldorf: full-time co-developing + co-architecting + dev-coaching (Go microservices in k8s with RPC as well as REST-ful APIs) for & with an agile product team building in-house cloud infrastructure at major global retail concern METRO's IT company

Authors of compilers for Pure Functional Programming languages with as rich, extensive and extensible type-systems as the current-gen "ML family" (top-spots Haskell, Elm, PureScript) seem to find it challenging to formulate many-if-not-most of their compiler's error messages —typically arising in already highly abstracted, über-generalized "meta-sphere" contexts— in a manner that won't frustrate practically all beginner and intermediate users, plus a substantial number of veterans. As a result, complaints about "cryptic errors" abound and often top the lists-of-criticisms in most threads about Haskell and PureScript.

Objective: to understand how an ML-ish -to-imperative/OO code generator (such as —in this example— the PureScript-to-JavaScript transpiler) represents functional type-classes (FP's approximate use-case equivalent to OO's interfaces).

JSON schema (JSD) files are great for exposing interchange formats of REST APIs, DB schemas, custom protocols etc. to external code. Given such a JSD definition, this package generates all the Go code necessary to load JSON documents of the therein-described format into the correct, fully commented/documented (likewise from the JSD) runtime data struct(ure)s.

A commissioned Go package providing a higher-level API for simplified RabbitMQ message-queuing by wrapping-abstracting-streamlining streadway/amqp under the hood.

A generalized IDE back-end for plugin-powered text editors: multi-editor (only VS-Code for now, Sublime planned) and multi-language (Go + Haskell for now, easily-extensible)

Any programmer often needs to output live data temporarily for inspection, serialized in a structured-but-human-readable format (think JSON) and in Haskell, using show on any Show able does this brilliantly. Alas it's missing indentation of course, its primary purpose being reproducable roundtrippable serialization. This is fine until it isn't (eg. with many 1000s of output "lines"-when-wrapped for just 4 Show ables while interoperating with Cabal).

For the "begintermediate" Funk(y-nota)tional Programmer, until more auto-math-ic intuition sets in, a quick-lookup cheat-sheet: examples of the built-in common standard instances for these two foundational Haskell typeclasses (for when GHCi isn't at hand, which it should never be).

Just happened upon these illuminative insights for "Developing an intuition for Monoid" — here are the essentials, distilled and/or paraphrased-for-clarity.

"controls" (aka. "components" aka. sub-templates aka. parametric-snippets aka. what-have-you-lets) ⋅ iterating renderers ⋅ HTML short-hand helper ('haX')tags ⋅ navigation helpers ⋅ page context / page metadata haXtags ⋅ mix-and-match-and-combine-and-nest any haXtags ⋅ embed haXtags anywhere (source contents, templates/snippets(-aka.-controls), project/config file) ⋅ some almost-enough-for-a-coder's-minimalist-blog-or-three "section-of-related-pages" notion called "Bloks" ⋅ globally shared (even-simpler-than-controls) textual/markup snippets of course ⋅ custom per-page variables ⋅ commonly desirable XML outputs ( sitemap.xml , *.atom ) ⋅ mod-time-differential rebuilds ⋅ per-page caching across runs ⋅ of course per-file-type templating ⋅ composable "named setups" ⋅ extensive configurability ⋅ some notion of "postings"/"simpleton data records"/"static tweets" micro-content definitions (with fully custom rendering) ⋅ easily defined, easily applied custom date-time formats ...

shared library with utility modules for text & list processing, configurability, debuggability, syntax sugars, convenience operators etc.

Showcasing my 2013-2014 work on high-performance, photo-realistic- lighting (so ignore the silly models I used here) GPU shader programs for mobile

Virtual database driver (implementing database/sql interfaces) with a backing store of local JSON or TOML data text-files as 'DB tables'.

Minimal web server for 'mostly static, mildly dynamic' sites in Go; stand-alone or on App Engine — runs this very web site ; includes a Bootstrap+jQuery-based seed-site

Utility library for cross-platform, core-profile OpenGL graphics programming in Go — 'sane no-overhead wrappers' for real-time use-cases

A DOM API library for handling Collada documents in Go code; supports Collada 1.4.1 and 1.5

Real-time, cross-platform 3D graphics engine library for/in Go (the next-gen C); runs on OpenGL Core Profile (v3.3 or newer) and GLFW; parallelized multi-core render pipeline ⋅ textured primitive meshes ⋅ scene-graph ⋅ cubemapped sky-mesh (cube, dome, etc.) ⋅ GLSL 'über-shader' permutation ⋅ post-processing FX ⋅ per-face multi-texturing / materials / effects ⋅ disk cache for on-demand pre-processed textures ⋅ render batching ⋅ frustum culling ⋅ HDR lighting ⋅ deferred shading

My go:ngine supports only one file format for importing assets: Collada. The format is quite expressive, going way beyond mere geometry meshes..

The 'swiss army knife' build tool of my dreams for Go projects: template-based code-gen pre-processor & documentation generator; run golint, go vet, or any other specified pre-build commands

A DOM API library for handling XML Schema Definition (XSD) documents in Go code; includes a source-code generator to instantly create 'native Golang bindings' for any given XML Schema Definition

...under OpenGL 3.2 core profile only, that is. Of course. That means some rather recent version of OS X required — not the latest but perhaps the one before — not sure right now which version introduced OpenGL 3.2 for Mac users. Elevating to see my OpenGL Go code running as a native binary under OS X!

Needed to hash a set of 3 unsigned integers into one integer value uniquely identifying-representing that particular sequence of uints, to be used as a "hash key" in a map[int]sometype ..

Getting seriously tricky stuff done in Go is, time and again, surprisingly simple:

All the general-purpose programming libraries I was missing in vanilla Go; includes imaging, hashing, DB, file I/O, networking, maths / numeric and string-processing helpers that I found indispensible in real-world Go programming