This is inspired by A half-hour to learn Rust and Zig in 30 minutes.
Your first Go program as a classical "Hello World" is pretty simple:
First we create a workspace for our project:
require 'logger' | |
logger = Logger.new(STDOUT, level: :INFO) | |
create_session = lambda do | |
require 'bunny' | |
Bunny.new({ | |
host: "rabbitmq", | |
port: 5672, | |
username: "guest", | |
password: "guest", |
This is inspired by A half-hour to learn Rust and Zig in 30 minutes.
Your first Go program as a classical "Hello World" is pretty simple:
First we create a workspace for our project:
///bin/true;COMPILER_OPTIONS="-g -Wall -Wextra --std=c99 -O1 -fsanitize=address,undefined";THIS_FILE="$(cd "$(dirname "$0")"; pwd -P)/$(basename "$0")";OUT_FILE="/tmp/build-cache/$THIS_FILE";mkdir -p "$(dirname "$OUT_FILE")";test "$THIS_FILE" -ot "$OUT_FILE" || $(which clang || which gcc) $COMPILER_OPTIONS -xc "$THIS_FILE" -o "$OUT_FILE" || exit;exec "$OUT_FILE" "$@" | |
#include <stdio.h> | |
int main() { | |
printf("Hello world!\n"); | |
return 0; | |
} |
I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.
This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea
Elixir Native UI - Boyd Multerer https://www.youtube.com/watch?v=77FW-jrCyCs
Thinking In Ecto - Darin Wilson https://www.youtube.com/watch?v=YQxopjai0CU
Author: Chris Lattner
require 'minitest/autorun' | |
require 'pg' | |
require 'mysql2' | |
require 'sequel' | |
def get_db(database_name) | |
case database_name | |
when :pg | |
Sequel.connect('postgres://pierre:@localhost:5432/pierre') | |
when :mysql |
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
(ns reduxish.state-tools | |
(:require-macros [cljs.core.async.macros :refer [go go-loop]]) | |
(:require [cljs.core.async.impl.protocols :refer [WritePort ReadPort]] | |
[cljs.core.async :refer [<!]])) | |
(defn channel? | |
"A predicate that determines if the provided thing is a core.async channel" | |
[ch] | |
(and (satisfies? WritePort ch) (satisfies? ReadPort ch))) |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
, elem.offsetTop
, elem.offsetWidth
, elem.offsetHeight
, elem.offsetParent