mattdw

New Zealand's TradeMe auction site just automatically delays the expiry by 2 minutes every time there's a bid within the last 2 minutes of the auction. The auction is not over until 2 minutes has passed with no further bids.

It used to live right at the top. Presumably Apple's is now the one most people are looking for.

Do signed types not also "break trivial math" like that, just at a different boundary? Genuine question. (The 0 boundary is obviously going to be more commonly hit than the 2^32 boundary, but nonetheless.)

Unfortunately the law provides no exemptions for media, or against public figures, and truth is no defense. All that is required is that you caused harm and it is found that you intended to.

So for example, exposing the corruption of a politician (online) may well be illegal under the act.

Swift is still (and will always be) automatically reference counted. Rust lets you closer to the metal. Rust also has much stronger safety guarantees – it's pretty easy to write Swift crashers that would just never compile in Rust. That's a big deal for the kind of software Rust is pitching itself at.

They do feel like quite similar languages; I'd think of them as a complementary Systems/Applications pair.

In the browser, Javascript (outside of webworkers) is single-threaded, and while running it blocks the browser run-loop (for the given webpage.) This means the page can't accept or respond to any incoming events. It's "blocked" from interaction.

In my experience, in the wide world of programming languages Rust and Swift are really not very far apart. Swift's designers even cited Rust as an influence.

It's JSON lists as s-exps, which means (as I understand it) that the author doesn't need to implement parsing, only traversal and evaluation. (Which can essentially be a big-ass case statement.)

    ["def", "foo", 1]
    ["fn", "foo", ["a", "b"], […]]

It's not the most attractive Lisp I've seen…

My first suggestion is to forget what you see on HN; it's totally not representative of most of the world's IT work.

Excel VBA and legacy business systems and nasty abandoned PHP and shitty Java monoliths are way more common out there than Angular and Node and the like.

"…solved many business problems with languages I didn't previously know, such as Excel VBA" sounds like it would make you a fantastic employee for any number of small businesses out there, the trick will be finding them.

I lucked into my first gig via a short-term contract (through a friend) that turned into full-time employment. The job was a mix of Filemaker (which I'd never touched before) and PHP and weird CSV import/export formats (so, basically the most awful combination of technologies in existence), but I solved real problems and was of real value to my employer. Sounds like you could pretty easily do the same, you just need to look for the opportunities.

The stuff that gets talked about on HN seems to be a weird microcosm of cutting edge tech, too much money, and "we have to convince investors we're worth buying so we have to keep up with all the buzzword tech". Meanwhile the other 99% are just tucked away in small businesses solving boring business problems with boring legacy tech and keeping the world turning.

Oryx and Crake by Margaret Atwood

Any of Ursula K Le Guin's books, but particularly The Left Hand of Tomorrow.

Ancillary Justice.

Anything by Peter Watts or Iain M Banks.

There's a case currently in front of the employment courts here in NZ which is confronting this directly. A group of aged-care nurses (working in retirement homes etc.) have made a claim to the employment court that (a) it's a female-dominated vocation, (b) it's lower paid than other similar vocations (by demands, skills, qualifications etc) and (c) that (a) and (b) are linked.

The case has made it through preliminary hearings and is now proceeding to a higher court; if they win a massive precedent will be set, allowing for claims of gender discrimination at the level of entire industries and vocations.

(I think it's totally a fair claim.)

Humans tended to hunt animals to exhaustion. The sprinting predators you're talking about stalk in close then sprint to take down their prey; groups of hunter-gatherer humans have instead tended to chase animals a long distance at moderate speed until the animals drop from exhaustion. It makes it easier to take them down, when you consider that humans are not really going to be jumping on the back of a buffalo and biting its neck to kill it.

So you don't tend to see animals running for hours because that's a human speciality (among predators), and it's part of why we've been so successful as a species, despite our physical weakness compared to other predators.

Or, to put it another way, the design process happened in the open, and you got to see some perfectly normal things that just wouldn't usually be visible to you. (And even have some input into them, if you were so inclined.) I don't really think that deserves criticism.

They have obviously changed the copy in the last few hours. The second half of that sentence ("Using…") was not there earlier.

I'm not saying that I wish that it were true, or that I think it's a good thing. I agree that it's daft. But over the short term, pillaging societies appear to beat conserving ones. And it's a fact that we do seem to be (as a species) adopting a short-term-profitable long-term-suicidal approach.

(An interesting model is Norway's oil – they're maximising in the sense of getting all the oil out from under the sea, but they're stashing most of the profits away as a rainy-day fund, which puts the country on very secure footing for about the next hundred years or so. You might call that 'maximising without consuming', or 'camping'.)

I think the future of the human race depends on finding a better answer to this whole question, but I think accepting that pillagers beat conservers in a lot of cases is a necessary step to finding something better.

(I don't think we actually disagree; we seem to be arguing different points.)

Perhaps, though, computing resources are priced artificially low due to externalities (e.g. third world wage inequality, environmental impact not paid for), and perhaps a sane long-term approach would find a different balance between programmer wages and physical tech components.

Maximising deprives others of the resource, optimising doesn't. I think that's the point being made.

An economy that first maximised, then second optimised, would beat an economy that first optimised, then second maximised, because the latter would have nowhere to expand.

An economy that optimised and maximised would beat an economy that only optimised.

Devs and designers are now (more so than ever) different sets of people, and designers are now calling the shots in most places.

I'm a web dev, I know that ajax loading sucks, that without enough budget to do it right (and we never have enough budget) UX ends up broken, messing with scrolling sucks, page-based is best, don't make an app if it should actually be a site, etc.

Do I get any say? Not really. What do I end up building? Magic-scrolling ajax-loading apps, and if I have any budget left at the end of the job it goes on tweaking typography (i.e. designer-visible stuff) rather than fixing back buttons.

Which is to say, devs still know that this stuff sucks, but we're no longer in charge of the relevant decisions.

I assume coroutines could be trivially implemented with sync_channel(0), which blocks the sender until the receiver takes the message. (And the receiver blocks until there is a message available.)

The 'generator' use of coroutines could be implemented with Receiver::iter, which is an iterator over a channel.

(As I understand it, coroutines are just a special case of channels.)

[Edit: see <http://doc.rust-lang.org/std/comm/> for channel docs]

If your game is at all taxing in terms of performance, you may find that neither give you enough visibility into, or control over, allocations and garbage collection.

I suspect particularly that ClojureScript (which would otherwise be my choice), with its use of persistent/immutable types and collections, might burden the GC quite heavily for a game.

CoffeeScript, IMO, offers so little over JS that it's not really worth the trouble.

It took me so long to figure out that "where is the monad?" was the wrong question. It took me even longer to grok that "monad" is essentially an interface/trait rather than a "type". I think your suggestion of 'monadic' is a big improvement.

My projects are generally quoted, so a lot of this is not always relevant to me (although they affect how I quote things), but, my thoughts:

- Learning core software/skills is not billable. "Core" is "any decent dev in this niche already knows this stuff." That's the stuff you read up on in your evenings. (One way my main client works around this is to have a senior dev always quote the tech side. Even if a junior dev does the work, they only get paid the quote, so they effectively self-adjust their hourly rate according to their skill level.)

- I would charge (and have charged) reading the docs, figuring out how to compile, and integrating a third-party payment lib I'd never seen before. So, specific tools/libs outside of the norm, I consider chargeable.

- Research for what I do is usually a write-off, but I can sometimes work a couple hours into the quote for a prototype if there are big unknowns. Or, before quoting, I say "give me a couple of hours to prototype, with the understanding that if we go ahead it's a component of the quote, if we don't go ahead you'll pay me anyway." Sometimes I don't charge the prototype, but it's instrumental in convincing the client to go ahead at all, so it's still a win.

- Tangent of a tangent, but kinda related to your 'research' point – quoting is really hard, mainly because quoting thoroughly approaches the complexity of doing the work for real. So a lot of my quotes are "if things go how I hope they will this will take 1 hour. If things go badly I'll come back and talk to you because we could be looking at days." Unknowns are really hard to quote without just doing the work.

I guess I'm not suggesting you necessarily have to charge the survival rate, but it's worth knowing the absolute least you could charge and still survive. It's just a "zero" to calibrate your expectations against, so when someone says "that sounds high" you know that it's not actually that silly, compared to your baseline.

Honestly, I'm not sure that anyone can answer this for you. As a freelance web dev myself, I can barely answer it for myself.

I suggest starting by setting a bare minimum for yourself – the rate you need to charge to survive. Freelancing should probably be about double the rate of full-time employment, as you have a lot of unchargeable (or just plain idle) time, so you have to allow for that.

Then, it's really just a matter of looking around and trying to figure out what other people are earning for similar work. It also helps if you have some idea of the value you're providing for your clients, as your rate should be roughly proportional to that.

For instance, I know one of my main clients charges out (both my time and theirs) at a flat rate of NZ$150/hr, and a bunch of their time is unbilled, so the NZ$80 they pay me is in the "reasonable" zone (especially for pretty solid guarantees of ongoing work). My "survival" base rate would be about NZ$60/hr (NZ$40/hr at the kind of hours I manage to bill wouldn't really provide me a living.)

But like I say, you're in entirely different circumstances to me, so the details don't really translate at all. It's a matter of (for all of us) figuring it out for yourself, really.

Because Rust's "managed" benefits are compiled away, they have zero runtime impact. Meaning that there's no reason it couldn't be as fast as C/C++ for all workloads. So you get a safe language with bare-metal performance. (Bare metal like, people have written basic OS kernels in it.)

> "Let the market work."

The market includes feedback mechanisms. Game criticism is one of said feedback mechanisms. If people are criticising a game, that is an element of the market at work.

To be fair, I'm on-side with the idea of an environment that adds niceties for your language. However, I agree that you should be able to still have a decent experience without installing or setting up language-specific editors or environments. I've really enjoyed being able to get into Rust with nothing more than Vim and a terminal.

Pretty familiar with Emacs, nrepl etc. Just a question of having enough time to familiarize myself with the ins and outs for any given new variety.

I actually did the ClojureScript tuts via LightTable, which was slightly less complex than the alternatives, but still required a bit of fussing.

(Incidentally, modifying my emacs setup in order to work on a project is the very definition of "incidental complexity".)

I really like Clojure (and have enjoyed David Nolen's CLJS tutorials and guides), but I find ClojureScript to have terribly arcane tooling. Despite being familiar with Clojure, it's still 10 minutes of cargo-culting and copy-pasting before I can start actually working on a ClojureScript project. Slightly ironic for a language which places such an emphasis on removing "incidental complexity."

My approach is (1) use CSS for as much as I can, (2) fill in the important compatibility gaps with JS (polyfill style) then (3) use JS to layer on any extra behaviours. That approach seems to play the best with the widest variety of configurations, and everybody gets something at least 80% usable. (With exceptions; I'm not talking about pure JS 'apps'.)

My thinking with the above is that CSS code paths in the browser are (with a very few exceptions) going to be a lot faster than trying to do the same in JS, and you don't have to wire up e.g. onresize handlers yourself.

Some things I'll just ignore; if your browser doesn't support border-radius or text-shadow, you get square corners and flat text; if your browser doesn't support box-sizing, the layout will be wrong but at least everything will still be visible.