ssalbdivad

Here's a comparison between how the same simple user definition would be defined using ArkType and Zod:

ArkType's definition syntax is more concise (definitions are about 50% shorter on average) as well as making it more visually obvious what the inferred TypeScript type will be. The ability to infer TypeScript definitions directly is the same, but ArkType's syntax is again more concise by allowing you to use typeof on a property of arkUser directly instead of using an extra "infer" helper.

In general, we also have taken significant steps to optimize and clarify our type hints when hovering over validators. For example, in the case above, this is what you see when you mouse over "zodUser":

akwodkiewicz

/**
 * Tells you how long ago was `inputDate` in "x days/weeks/months ago" format using `Intl`
 * ({@link https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl docs}).
 * Automatically changes the resolution from days, to weeks, to months, to keeps things readable.
 * Returns the exact date if the `inputDate` happened very long time ago.
 *
 * Dates only, time is ignored.
 *
 * You can use `forcedLocale` to get the string in a specific locale, otherwise a browser locale
 * is used.

AlexxNB

We should have at least three files: 'Widget.svelte', 'rollup.config.js' and 'package.json':

1. Our widget Widget.svelte:

<script>
	export let name;
</script>

<h1>Hello {name}!</h1>

coderaiser

Try-catch oneliner

If you search npm with query try await you will find a big modules list (you can find it in the boottom).

What all this developers want is just more clear way to use try catch. All of them suggest to use:

const tryCatch = require('try-catch');
const [error, data] = tryCatch(JSON.parse, 'hello');

erincandescent

Foreward

This document was originally written several years ago. At the time I was working as an execution core verification engineer at Arm. The following points are coloured heavily by working in and around the execution cores of various processors. Apply a pinch of salt; points contain varying degrees of opinion.

It is still my opinion that RISC-V could be much better designed; though I will also say that if I was building a 32 or 64-bit CPU today I'd likely implement the architecture to benefit from the existing tooling.

Mostly based upon the RISC-V ISA spec v2.0. Some updates have been made for v2.2

Original Foreword: Some Opinion

The RISC-V ISA has pursued minimalism to a fault. There is a large emphasis on minimizing instruction count, normalizing encoding, etc. This pursuit of minimalism has resulted in false orthogonalities (such as reusing the same instruction for branches, calls and returns) and a requirement for superfluous instructions which impacts code density both in terms of size and

SimonAlling

// Types:
type Just<T> = { Just: T }
type Nothing = {}
type Maybe<T> = Just<T> | Nothing

type Left<L> = { Left: L }
type Right<R> = { Right: R }
type Either<L, R> = Left<L> | Right<R>

// For convenience:

patrick-steele-idem

Syntax: Marko vs Vue

Custom tags and passing data

Marko:

<greeting
  name=fullName
  message-count=30

matteocrippa

#!/usr/bin/env bash

# Brew
echo "Installing 🍺 Brew!"
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo "eval $(/opt/homebrew/bin/brew shellenv)" >> .zshrc

# Tap
brew tap homebrew/bundle
brew tap homebrew/core

cdsousa

Here's the canonical TOML example from the TOML README, and a YAML version of the same. Which looks nicer?

title = "TOML Example" [owner]

robertpainsi

Commit Message Guidelines

Short (72 chars or less) summary

More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).

Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages