Graham Jenkins writes about Go, Rust, Linux internals, and code quality, including a post on building a tiny Rust binary.
HN commenters link it for the guide to building a tiny Rust binary of around 500 bytes, and for the critique of Facebook's code quality.
Facebook is the world's largest PHP shop. Does that mean that everyone should use PHP?
As it turns out, moving fast and breaking things isn't all that conducive to quality engineering[1][2]. Facebook has a massive legacy code base maintained by an enormous team that is under pressure to iterate quickly while supporting what is arguably the world's largest user base. They are dealing with extremely specialized constraints that most of us will never encounter. Many of the trade-offs they consider acceptable aren't trade-offs that make sense elsewhere.
And that's exactly what the blog post is getting at. A lot of these emerging technologies are situationally useful in a particular set of scenarios and environments, but developers with cargo cult mentality convince themselves that these things will solve all of their problems if they use them everywhere. When the disappointment sets in and they figure out that isn't the case, yesterday's darling stack becomes the subject of today's "considered harmful" essays and everybody moves on to the next shiny thing.
The point here is that maybe you should make a sober assessment of new technologies and objectively evaluate whether they are actually practical for your usage scenario rather than just blindly jumping on the bandwagon and using something.
The examples from the blog post are totally on point. I previously worked at a company that built a NoSQL database and I have great affinity for the technology, but there's no question…
Yes, I think the promises of the "we can JIT all the overhead away"-camp were always overblown, and never materialized in practice. This is another very strong datapoint for that hypothesis[1].
However, it is important not to conflate "scripting language" and "dynamic language" and "interpreted". While there is some correlation there, it is not a necessary one.
Objective-C is an example of a fast AOT-compiled pretty dynamic language, and WebScript was an interpreted scripting language with pretty much identical syntax and semantics.[2]
What do I mean with fast? In my experience, Objective-C can be extremely fast [3], though it can also be used very much like a scripting language and can also be used in ways that are as slow or even slower than popular scripting languages. That range is very interesting.
So I don't actually think the tradeoff you describe between low-level unergonomic fast and high-level ergonomic slow is a necessary one, and one of the goals of Objective-S is to prove that point.[4]
So far, it's looking very good. Basically, the richer ways of connecting components appear to allow fairly simple "scripted" connections to achieve reasonably high performance [5]. However, I now have a very simple AOT compiler (no optimizations whatsoever!) and that gives another factor 2.6 [6].
Steve Sinowsky wrote: "Does developer convenience really trump correctness, scalability, performance, separation of concerns, extensibility, and accidental…
I've seen medical stuff and there's a good reason I won't work in that industry...
What REALLY bothers me is things like credit cards.
http://www.merriampark.com/anatomycc.htm
There's encoded data on something that's supposed to be a UUID thing: Industry, Issuer (card company), Lender (banking institution), Account number, and Checksum
This is a good way to prevent fraud? Or have they just given me the keys to generate "valid" credit cards?
http://www.darkcoding.net/credit-card-numbers/
Slap a name from the phonebook on there and see what you can purchase. Now we have PCI compliance trying to tell people to somehow lock this crap down? So they invent the CV2 codes, a 1 in 1000 hit-or-miss, I don't think my odds are too bad when I can generate any creditcard. Dates will also only fall into a specific range of time anyway. Yeah, we keep putting up bandages to creditcard security processing, but why do we need to? Honestly, the world of standards sucks.
> If your slice has a million entries, it's definitely a different story.
Searching through a map is much faster than you think. At 20 entries searching through a slice of strings is already slower than searching in a map. For ints this threshold is 100 entries. Feel free to test on your own machine, my benchmark code is here: https://gist.github.com/JelteF/1251f180966eb974d7732ea6c3d3b7ff
You can run it with:
go test -bench='.' -benchtime=1s slicemap_test.go
The benchmark code is based on the one from this blogpost: https://www.darkcoding.net/software/go-slice-search-vs-map-lookup/
After looking at that code though I didn't trust the results too much anymore, because of various issues with it. So I decided to fix those issues.
I got a Rachel from Cardholder Services call once during an in-office meeting so I put the call on speaker for everyone to enjoy, then immediately went to Graham King: https://www.darkcoding.net/credit-card-numbers/ to get some credit-card numbers that would pass their basic Mod 10 check and go to their CC merchant service, thus costing them money. By the sixth failed card and 20 minutes later the 'agent' figured out I was messing with him and threatened to rape my wife and kill me while screaming obscenities. It went very NSFW in a matter of seconds.
Very nicely presented. My credit card page and code have been top search result for years - it's about time someone improved upon it! Thanks.
http://www.darkcoding.net/credit-card-numbers/
http://www.darkcoding.net/credit-card-generator/
If the code on darkcoding helped you build your project (we have the exact same card issuers), could you give attribution?
It would also be very cool if you open-sourced that site. The code on darkcoding is GPL, not AGPL, so you're not required to. Would still be cool of you :-)