Adelar da Silva Queiróz adelarsq

Let's Destroy C

I have a pet project I work on, every now and then. CNoEvil.

The concept is simple enough.

What if, for a moment, we forgot all the rules we know. That we ignore every good idea, and accept all the terrible ones. That nothing is off limits. Can we turn C into a new language? Can we do what Lisp and Forth let the over-eager programmer do, but in C?

Classes with properties and default constructor

type Vector(x : float, y : float) =
    member this.X = x

raylib: 6 years of fun

raylib has been in development for more than six years now, it has been an adventure! I decided to resume how it was my personal experience working in this free and open source project for such a long time. Just note that the following article explains raylib from a personal point of view, independently of the technical aspects and focusing on the personal adventure; for technical details on raylib evolution, just check raylib history and raylib changelog.

raylib inceptum

Summer 2012 was ending, I had been working hard on my brand new startup emegeme for about 9 months, developing videogames. I was trying to find my blue-ocean, so, I developed and published two games for Windows Phone platform using the ama

Rust in Large Organizations

Initially taken by Niko Matsakis and lightly edited by Ryan Levick

Agenda

Introductions
Cargo inside large build systems
FFI
Foundations and financial support

Announcing cargo-udeps

One of the biggest issues that most people have with Rust are the long compile times. One of the reasons why compile times are so long is because many projects use quite a few dependencies from crates.io. Your dependencies have dependencies of their own, and they in turn have dependencies as well, and so on. This results in really big graphs of crates that all have to be compiled by cargo. Sometimes however, a crate actually doesn't use anything of some of its dependencies. Then those dependencies can be removed, resulting in faster builds for that crate. But how do you detect them? Often they sit in Cargo.toml for a long time until someone discovers they are actually unused and removes them (example). This is where cargo-udeps comes in. cargo-udeps is an automated tool to find dependencies that were specified in Cargo.toml but never used in the cra

Architecture

Use Onion architecture
- Dependencies go inwards. That is, the Core domain doesn't know about outside layers
Use pipeline model to implement workflows/use-cases/stories
- Business logic makes decisions
- IO does storage with minimal logic
- Keep Business logic and IO separate
Keep IO at edges

Charts are from different sources and thus colors are inconsistent, please carefully read the chart's legends.

Like this? Check React Native vs Flutter: https://gist.github.com/tkrotoff/93f5278a4e8df7e5f6928eff98684979

Stack Overflow trends

https://insights.stackoverflow.com/trends?tags=reactjs%2Cvue.js%2Cangular%2Csvelte%2Cangularjs%2Cvuejs3

I've been deceiving you all. I had you believe that Svelte was a UI framework — unlike React and Vue etc, because it shifts work out of the client and into the compiler, but a framework nonetheless.

But that's not exactly accurate. In my defense, I didn't realise it myself until very recently. But with Svelte 3 around the corner, it's time to come clean about what Svelte really is.

Svelte is a language.

Specifically, Svelte is an attempt to answer a question that many people have asked, and a few have answered: what would it look like if we had a language for describing reactive user interfaces?

A few projects that have answered this question:

	module AdaptiveSample

	open Fable.React
	open Fable.React.Props
	open FSharp.Data.Adaptive

	let useAdaptive (v: aval<'T>) =
	// initialize hook with initial value
	let stateHook = Hooks.useState (AVal.force v)
	let onChange () =