ctrlcctrlv

Rust maintainer perfectionism, or, the tragedy of Alacritty

I did not submit this to Hacker News and did not intend that this post would have high circulation but have no real problem with it being there or with it having such. I have more recent comments below. This post is from January 2020 and predates the Modular Font Editor K (MFEK) project.

I have not worked on Rust projects in quite a while, and don't know if I ever will again. I feel many crate maintainers are way too perfectionist, for example, despite all the developer hours that went into this PR, it took the effort within years to be (halfway) merged.

There's always a reason not to merge, isn't there? It would be better done with a new nightly language feature, or the function signature should have a where clause, or the documentation is not perfect. There's always a new nit to pick in the world of Ru

dominictarr

Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.

@broros

otherwise why would he hand over a popular package to a stranger?

If it's not fun anymore, you get literally nothing from maintaining a popular package.

One time, I was working as a dishwasher in a restu

gragland

import { useState, useEffect, useRef } from 'react';

// Usage
function App() {
  // State value and setter for our example
  const [count, setCount] = useState(0);
  
  // Get the previous value (was passed into hook on last render)
  const prevCount = usePrevious(count);
  

mathiasverraes

<?php
// Context: I'm trying to argue that DI (and DIC) are great, and DIC libs suck. 
// Happy to be proven wrong!

final class Router {
    private $dependencies;
    public function __construct (Dependencies $dependencies) {
        $this->dependencies = $dependencies;
        // You might say that this is Service Locator, but it's not. This router is toplevel,
        // and toplevel must have access to dependencies. After that it can all just bubble nicely using proper DI.

vjeux

I'm taking down this post. I just posted this as a side comment to explain a sentence on my latest blog post. This wasn't meant to be #1 on HN to start a huge war on functional programming... The thoughts are not well formed enough to have a huge audience. Sorry for all the people reading this. And please, don't dig through the history...

dannote

#!/usr/bin/swift

import Foundation

let path = URL(fileURLWithPath: NSString(string: "~/Library/Application Support/.ffuserdata").expandingTildeInPath)
let data = try! NSData(contentsOf: path) as Data
let dictionary = try! NSKeyedUnarchiver.unarchiveTopLevelObjectWithData(data) as! NSDictionary
let mutableDictionary = dictionary.mutableCopy() as! NSMutableDictionary

for (key, value) in mutableDictionary {

joepie91

The One Secret Trick To Becoming A Genius Programmer

Okay, the title of this post is a bit of a lie. There's no one secret trick to becoming a genius programmer - there are two, and they're more habits than tricks. Nevertheless, these kind of 'secret tricks' seem to resonate with people, so I went for this title anyway.

Every once in a while, a somewhat strange thing happens to me. I'll be helping somebody out on IRC - usually a beginner - answering a number of their questions in rapid succession, about a variety of topics. Then after a while, they call me a "genius" for being able to answer everything they're asking; either directly, or while talking about me to somebody else.

Now, I don't really agree with this "genius" characterization, and it can make me feel a bit awkward, but it shows that a lot of developers have a somewhat idealistic and nebulous notion of the "genius programmer" - the programmer that knows everything, who can do everything, who's never stumped by a problem, and of which ther

samthor

// UPDATE: In 2023, you should probably stop using this! The narrow version of Safari that
// does not support `nomodule` is probably not being used anywhere. The code below is left
// for posterity.

/**
 * Safari 10.1 supports modules, but does not support the `nomodule` attribute - it will
 * load <script nomodule> anyway. This snippet solve this problem, but only for script
 * tags that load external code, e.g.: <script nomodule src="nomodule.js"></script>
 *
 * Again: this will **not** prevent inline script, e.g.:

hikari-no-yume

<?php declare(strict_types=1);

require_once "✨.🐘";

✨($_)->strlen("foo")->var_dump($_);

hallettj

# Makefile for transpiling with Babel in a Node app, or in a client- or
# server-side shared library.

.PHONY: all clean

# Install `babel-cli` in a project to get the transpiler.
babel := node_modules/.bin/babel

# Identify modules to be transpiled by recursively searching the `src/`
# directory.