msbarnett

Reading anything at all into the relative performance of these programs written by different people which are all doing radically different things seems like a gigantic waste of time.

Some of these “simple” versions are custom-specifying allocators to minimize memory overhead and doing highly optimizable ASCII value manipulations and doing byte-equality on strings, rather than go through slower Unicode libraries. The “simple” Swift version is doing nothing at all to avoid generating many allocations/deallocations and running fully Unicode-aware algorithms to lower the input and perform Unicode-normalized string comparisons, it’s totally apples-to-oranges stuff.

> TLDR: Basically, want to be able to state that branch depends on branch (which is currently commit id x) but if I rebase, use whatever the current commit id is for that branch, not whatever it was when I first made the branch.

As far as I can tell (the “problem” you’re describing is a bit vague) this is already how git works with the sole exception being that git doesn’t default to a particular branch for a rebase?

eg) all you seem to de describing here is a bog-standard:

     (on feature-branch1)> git checkout -b feature-branch2

<do some work on feature-branch2, return to feature-branch1 and make some more changes there, now you want to catch feature-branch2 up with feature-branch1>

     (on feature-branch2)> git rebase feature-branch1

<now we’re branched off of the new tip of feature-branch1, not where we originally branched>

All it seems like you’re asking for us to drop “feature-branch1” from the rebase?

> But the gig employee is the business.

Rather, the gig employee (note that word even you used, “employee”?) is a thinly veiled fiction the actual business uses to offload risks and avoid having to pay benefits.

If the gig employee was a real business they could set prices, choose how to go about doing the job (routes to take to destination, etc), market themselves instead of acting as an interchangeable cog in the real businesses’ app, etc, etc, etc, etc

“There’s definitely a crisis of nobody wanting to work anymore, unlike the last hundred years of people saying this”

lol c’mon. The ol’ “$CURRENT_GENERATION is uniquely weak/lazy/bad, unlike $SPEAKER_OWN_GENERATION” chestnut is a nice touch, I’ll give you that.

The details of why the bad deal is bad are good color, but don’t really change that it’s not a great deal.

I do a heck of a lot more with my internet connection than just streaming – there was a night-and-day improvement when stepping up from my previous 150 Mbps coax connection. It’s not just “large game downloads”, but moving many gigs of data to remote servers daily as part of my job while both my wife and I are in video calls, while also etc etc. Fast symmetrical fiber is a godsend.

But whether or not these speeds would be meaningfully useful to you personally, the real observation here is just that GP is paying ~4.7x as much on a Megabit per second per month basis – your 20Mbps “I just stream” connection should cost hardly anything, a bad deal however you slice it.

(As an aside: yearly phone replacement?? I buy hardware to last on a much longer timeframe, so it more than balances out)

edit: back of the envelope network stat math – the 7.5TB I moved last month (up+down) would have completely saturated a 20Mbps connection for more than the month (34 consecutive days), assuming it was symmetrical (which a connection like that probably isn’t).

Looking at the exchange rate, I’m paying ~£65/month for 1Gbps unlimited fiber in Canada, which is not exactly known for its cheap internet.

£20 a month for only 65Mbps seems not great to be honest.

I would imagine that depends on whether they’re employed by a hospital or incorporating themselves and running their own private clinic.

If you’re a salaried SWE, obviously expense the $150. But for a contracting SWE? $150 is really nothing compared to what a woodworker, wedding photographer, welder, or most any other self-employed professional has to spend on their tools.

I once had people screaming bloody murder at me here on HN for suggesting that, for a professional North American software engineer making a typical US SWE income, a one-time $150 purchase of a tool you would use daily in your professional capacity was totally reasonable.

There’s a baffling disconnect here between how people perceive their own value of time while feeling entitled to the product of others’ time for essentially nothing.

Ruby, like Lisp, really really heavily prefers and benefits from REPL-driven exploration and development.

You don’t necessarily have to figure out how to call the calling function, but you will want to use the REPL to evaluate the above code in an instance’s binding with instance_eval or the like, or use Class.method(:blah) to get the method object, or etc. Or if this is Rails, stick a binding.pry in the controller and get a REPL at the point while you’re interacting with the app in a browser, etc.

The ability to get a full REPL anywhere and explore and manipulate the program interactively is one thing I deeply miss when working in less dynamic languages.

> A C data structure is never a disaster of "thread unsafety" if, like most data structures, you don't use it across threads

lmao. profound stuff man.

> It's not a religion where apostasy is punished by castration.

What on earth are you even talking about. It was just a metaphor for runtime crashes you absolute dingus.

> I'm criticizing Stacked Borrows because I've seen more than enough evidence that it's an unreasonably stringent memory model for writing unsafe code

I didn’t ask! I don’t care! At no point in my life have I cared about anything less than I care about what “nyanpasu64” thinks about Stacked Borrows. Take the hint you tedious dork.

> Are you seriously arguing that C linked lists are just as wrong as Rust ones, by saying a CS student is as likely to write an incorrect C linked list as a hardened professional is to write an incorrect Rust linked list

What?

No, I’m saying that writing a linked list in C is “easy” if and only if your implementation doesn’t even bother to try to cope with the 9000 foot guns C offers you — that your easy C graph data structure is basically always a disaster of Undefined Behavior and thread unsafety, because if you try to make it otherwise, it will cease being at all easy. It will become in fact really fucking hard

So when I say “you can have your easy C-style linked list in Rust, just use unsafe”, I agree entirely: the Rust implementation will also likely be a gigantic clusterfuck of Undefined Behavior. That’s the entire point: it’s only ever easy in either language if you’re willing to blow both of your feet and you dick clean off. It’s easy only if you’re so inexperienced and naive that you don’t even perceive the dangers of the highly efficient dick-and-leg removal device you’ve built in C, and whine on forums about how mean-old-Rust is hard in comparison because it keeps refusing to compile your dick_exterminator.rs file.

That’s the Apples to Apples comparison. Which unsafe thing is harder to get right, I don’t honestly give a flying fuck about. Now, it’s highly de-fucking-batable that it’s easier for “an expert C programmer” to avoid undefined behavior entirely in an arbitrary mutable graph implementation in the presence of multithreading unless we’re talking about an entirely mythical level of expert here, but that’s utterly offtopic to the discussion at hand. You were just looking to grind a fucking axe about Stacked Borrows and decided to rant at me about it, but it really has fuck all to do with anything I was saying, man.

You can have an easy graph structure in Rust in the only way you can easily have one in C: by not giving a single shit about correctness.

I’ve written both professionally and personally found Python makes it harder to see the early out, which makes it less valuable/explicit as a guard.

The Ruby pattern is clear up front on what it is rather than being a bag of conditions that you have to get to the end of to discover what they trigger.

How does this make it confusing? What information do you feel () gives you?

You might say:

      foo().bar().baz()

Ah well these are clearly method calls, they have ().

But this is Ruby:

      foo.bar.baz

These are clearly method calls too, because in Ruby there’s nothing else they could possibly be. The ()s don’t actually disambiguate anything. Unlike C or Java or some other languages with some notion of bare access to internal fields, there are always and only method calls.

What “lost”? They’re both Top 10 most used languages with tens of thousands of open positions currently available for someone competent in either.

Python’s the more frequently used of the two industry-wide, but it seems like they both won, just with different crowds.

If anyone very finds themselves hunting around for a method definition like this,

    method(:blah_changed?).source_location

is your new best friend.

And The “easy” C sophomore computing science graph is inevitably chock full of Undefined Behavior too, the implementers just never noticed or gave a shit because they cobbled something together that looked superficially correct, the compiler didn’t complain, so they decided they were all good. Sophomores, as it turns out, are hardly world-beating experts in C standard esoterica.

The rest of what your wrote is completely irrelevant to the original point: this seems hard in safe Rust only because you’re comparing it to doing something totally different and simpler in C.

Grind your axe about stacked borrows elsewhere.

That’s really only a problem if you spend a significant amount of time trying to “build data structures from introductory algos” without reaching for unsafe, though.

If you find it easy to build a linked list or graph in C, you can do it just as easily in Rust — use unsafe, and you have your easy linked list, with exactly as much safety as it had in C. Sure, it’s more challenging to build a fully memory and thread safe linked list or graph, but it’s actually hard as hell to do that in C too. Other languages make it easy to build one with these guarantees only by requiring significant runtime support, which is out of scope for Rust.

In the end, it’s pretty unrealistic to expect that any language would allow you to write a guaranteed memory and threadsafe graph structure with zero runtime overhead, without a lot of knowledge, time, and attention on your part — there are no silver bullets.

And if you’re using Rust for anything real you’re generally not doing sophomore computer science homework like this anyway.

> But this kind of branding wasn't as prevalent before web apps invaded the desktop.

This is ahistorical. App branding now doesn’t hold a candle to the late-90’s mania for every app having its own skin engine. App-vs-platform UI deviation is a lot tamer nowadays.

How on earth do you imagine a blockchain makes customer support go away?

This is equally true of buying drugs on the darknet using BTC.

> All I’m talking about is a simple ledger, not the fancy smart contact nonsense.

You wrote:

> > A private “coin” between mostly trusted partners with provisions for reversing transactions as needed.

Either you’re doing that with a smart contract, or you’re just plain trusting the other people to reverse it when asked, in which case there’s zero reason to be using a blockchain to begin with.

You don’t want or need trustless ledgers to interact with trusted parties - that’s a big increase in complexity for zero gain.

I do all of those things with actual money.

> Interbank nightly balance settlements between large institutions. A distributed cryptographic ledger would be great for this kind of thing. A private “coin” between mostly trusted partners with provisions for reversing transactions as needed.

But they’re already trusted partners who already have a functioning settlement mechanism that already has provisions for reversing transactions. Jamming a blockchain on top of this solves nothing not already solved.

The claim that this would reduce maintenance overhead is hogwash – we’ve seen an unending litany of unexpected bugs in blockchain protocols and smart contracts, while the existing transfer mechanisms are already debugged. Trustless mechanisms are harder to get right than trust-based ones, not easier.

If you truly never enter credit card info on the web, or truly have zero expectation that other tabs shouldn't be able to spy on that credit card info when you do, then frankly you're so outside the range of normal people's expectations and behaviours that I don't think basing security architecture around what you do or don't do makes any sense whatsoever.

They need to be in different trust zones unless your willingness to enter a credit card into any website means you’re willing to allow every other website you may be visiting to observe that input. Ditto viewing bank information etc.

That’s the point: you can’t just pile every website into the same zone, and if you did pile them into the same zone, then using a different password for x.com and y.com is to some extent pointless because x can observe y’s password input and vice-versa.

(disregarding the fact that in current computing architectures “just put all the untrusted stuff on one core” is probably an insufficient solution due to shared caches anyways, no indeed nothing in this attack requires “sharing a core”)

I think you’re confusing hyperthreading (disabled on amd64 in OpenBSD) with speculation (neither disabled nor afaik disableable on amd64).

Is that even enough? Hyperthreading let some of the earlier spectre exploits work faster, but as long as there's some shared cached between two cores (L2 or L3), that's enough for timing variations to leak what's in that cache afaik. Maybe it's enough for this attack (unsure), but I don't think it solves speculative side-channel leaks in general.

> It wouldn't be impossible to create hardware with the concept of "infinite registers" that ultimately gets optimized away. (see: Mill CPU)

I'm not sure that the vaporware Mill CPU acts as an existence proof for anything, to be honest.

"Free-as-in-speech, not free-as-in-beer" is just expecting you the hearer to understand that while event advertisements might prominently feature the words "free beer" as an exciting statement that beer is being given away for zero cost to drive interest, zero cost is not the sense in which "free" is being used in "free software"