yberreby

A Promise-based API doesn't block the event loop, but a synchronous one like fs.readFileSync does. Their usage might look similar but their semantics differ vastly.

> I decided my internal caveman was not my friend, and took steps to sideline his vote in decision-making.

Could you elaborate on what those steps were?

If you can make your app fit in a single binary and you do not _need_ Docker's features, then yes, I don't see why you'd bother using it. Docker shouldn't be your immediate go-to. It's just another tool that can help with some problems.

Things do become more complicated when your app is a single logical unit that depends on a number of resources / services. Maybe you want an nginx reverse proxy in front of it, a database engine behind it; maybe Go isn't the only language you're going to use. Maybe you want the ability to effortlessly run the exact same setup as your production environment somewhere else without having to run a bunch of Ansible playbooks on the target host, and without worrying about the Linux distribution on it. Docker and docker-compose can help with these use-cases and get you up and running quickly.

I'm not saying Docker is ever a _necessity_. But it can be a great convenience. In the end, use the simplest solution that fits your requirements, and make sure you can extend it later on if those requirements change.

Because high compilation times can be a major turnoff, and the single-threaded performance of a beefy developer workstation is not that much higher than that of a regular machine. You can't always throw more cores at a problem, and Moore's Law hasn't exactly been holding true lately.

I'm unaware of an architecture named am64, so I assume you mean amd64, in which case that _is_ x86_64. Same ISA, different name.

Look into KeePass, it's better than an encrypted DMG :). There's a Mac implementation called MacPass which is really well-designed and easy to use.

Sounds like what you want a microkernel with excellent IPC. There is still the problem of the window manager, incompatible protocols, and backwards compatibility, but I think a very small, robust core with discrete components that communicate in an isolated way instead of sharing resources is the way forward.

If you start viewing the filesystem as a huge global variable, it becomes obvious that something is wrong with modern OS / app design. One wouldn't tolerate this kind of uncontrolled sharing in a regular program; why should we tolerate it in an OS? Permissions help, but don't solve the issue, as they are still an access control measure on top of an already flawed model.

But if the file you are removing is the only reference (i.e. hard link) to that inode, you're not just modifying the directory's contents; you're also removing data from the filesystem as a whole.

The accompanying blog post[1] might have been a better fit for submission, as it has actual content:

[1]: https://fly.io/articles/one-hostname-to-rule-them-all/

Nitpick: `std::ptr::null()` is not just there for C interop. It's also useful when writing pure Rust unsafe code.

Then it would seem that we agree, because I don't either. Christianity is definitely faith based.

I agree with you regarding "Let there be light" referring to the Big Bang. However, it's not unreasonable to assume that there might have been another source of light for these plants to grow. Alternatively, even if there wasn't, do you not think that a God who could create the Sun and the Earth from nothing would be unable to make plants grow without the Sun? It seems that many so-called 'rebuttals' of the Bible try to disprove it by explaining why some events are physically impossible, but what is impossible to an all-powerful God who created the laws of physics themselves? Is he not able to bend them to His will?

If one tries to nitpick on every little detail in the Scriptures, they will have a lot of occasions to do so. It is quite easy to find apparent contradictions by interpreting the Bible in a way that is suited to your goal. It is not, however, a proof that the Bible contradicts itself, as it relies on a specific interpretation. When it come to religious matters, very few things can be proven or disproven.

The way I see it, Christian faith is about being humble. You can't find God if you read the Bible with a self-righteous, know-it-all attitude, trying to disprove it line by line. I found this[1] page to explain this point of view quite well.

You cannot apply the principles of science to metaphysical matters, because science concerns itself purely with the physical, tangible world, and has no answers to offer regarding its origins, its meaning, etc. Science and faith do not contradict each other; rather, they complement each other. I like to think of myself as a highly rational individual; mathematics and programming, for example, delight me. Yet I have no issue believing that the Bible is true, and that the God of Abraham, Isaac and Jacob is the creator of the Universe. Does that make me a fool? In the eyes of some, yes. Is it possible to be cognitively biased in a specific area yet highly rational in others? Absolutely. But to say that reason precludes faith is simply incorrect.

[1]: http://www.christiananswers.net/q-comfort/contradictions-bib...

WebAssembly might be a big step towards improving that.

But it will not read outside of the buffer. It will panic at runtime instead. That's not a buffer overrun.

Yes, it does. Not all CPU cores are created equal. Performance depends on microarchitecture, cache size, memory bandwidth and latency, clock speed, hardware acceleration of specific features, and hyper-threading capabilities, to name a few.

Take the Xeon E5-2403[1] and the Xeon E5-2637 v4[2]. Both are quad-core Xeons, but they differ by pretty much everything except core count.

Here's a comparison of their performance: http://cpubenchmark.net/compare.php?cmp%5B%5D=1827&cmp%5B%5D....

Granted, this is an artificial benchmarks, but the results speak for themselves. In this case, the Xeon E5-2637 v4 is almost three times faster than its little brother, the Xeon E5-2403.

Quantifying CPU performance by number of cores is disingenuous at best, and dishonest at worst.

[1]: http://ark.intel.com/products/64615/Intel-Xeon-Processor-E5-...

[2]: http://ark.intel.com/products/92983/Intel-Xeon-Processor-E5-...

Did your previous MacBook have an SSD or a hard drive? What were its specs?

This article is very interesting, but it's unfortunate that its title says little about its content. I had no idea it was about Apple when I opened it, expecting it to be about the Go programming language instead.

> Why the 7th generation Intel chips?

I suspect the author meant "6th generation", or "why not the 7th generation Intel chips", because the new MBPs have 6th-gen (i.e. Skylake) CPUs.

What about Lisp-family languages' metaprogramming capabilities?

Consider that your recollection of the event is itself uncertain. Could it not be that although you now remember having known what was about to happen, you did not actually know that when the situation took place, and only subsequently formed that memory?

I originally posted this is as a reply to someone who commented about learning programming well before college on the article, but I think it could spark an interesting discussion here, so I'll paste it:

"I'm self-taught and started at 11. I'll start college next year. Would you be so kind as to provide some advice to someone who is in a similar position to you a few years ago?

It all started out as a center of interest among others, but grown into a passion, and today I know that I will work on software development. I've gained some experience along the way - worked on real-world, revenue-generating projects for relatives, read through a lot of technical books, and learned varying amounts of Python, Ruby, C, C++, JavaScript (client- and server-side), and Rust. As well as some HTML and CSS. I learned how to use the command line, how to administrate a UNIX system, the basics of information security (just enough not to make overly stupid mistakes as a developer), among (many) other less important things.

Python was my first 'real' programming experience. I 'know' C, but I wouldn't trust myself to write production software in C without a lot more experience. I can read C code, but writing a sizable amount of _correct_ C is not an easy endeavor. I wrote a few production utilities in Ruby and recently started to dabble in Rails. I got interested in game development and read a lot on the matter, so I just _had_ to learn C++. I did for about four months before learning JavaScript seriously. I learned to use JS client-side, and server-side with Node.js, which I used to sell Steam trading bots for peanuts. More recently, I learned Rust, which has been my most pleasant experience so far (static type checking, memory safety, close to the hardware with C-level performance? Sign me in!), and the language in which I've invested the most. I contribute to open-source projects whenever I can, hung out a lot on the #rust IRC channel and on the /r/rust subreddit for some time, and used the language to write a few small production utilities (a few kLOC).

I like to think that this is a great track record for a 16-year-old. However, my perception of my own skill level is what I'd describe as unstable. Sometimes I'll read through some particularly technical HN threads and feel like a pretentious idiot who knows no more than the bare basics. At other times I'll read stories about college graduates and 'professional' programmers with 5 years of experience who cannot seem _much_ less skilled than me, and I'll feel like I don't even need to go to college.

So I turn to you. Enlighten me. What new things will college teach me? How should I approach it?

Here's my GitHub profile in case you want to take a look: https://github.com/yberreby/ "

Why on earth were you downvoted? That seemed like a sensible comment to me.

That doesn't make it immune to memory unsafety, because the initial implementation had to be written in something other than Go, namely C. And the current compiler was compiled by an older compiler, which was itself compiled by an older one, ..., which was itself compiled by the initial Go compiler, written in C.

Hashing keychain passwords would make no sense. You hash passwords when you want to check against them. When you actually need to retrieve them at some point, however, you encrypt them.

There's an RFC that could address the lack of type-level integers: https://github.com/rust-lang/rfcs/pull/1657

> If we can treat Cargo as a pure function from inputs to outputs, we should be sharing these build results across the Internet, at least within the set of machines used by one person.

AFAIK, all it takes is a single `build.rs` to make rustc, and therefore Cargo, an impure 'function'. I'm not sure about compiler plugins, but I expect them to behave the same way.

That's not the only reason.

If I'm given the choice between a free proprietary, inflexible system like Apple Music, and paid DRM-free content that I own and can keep as long as I want (basically, paid pirated content), I'll choose the latter.

I don't see another autocompletion option than YCM with --racer-completer in my list, so yes and yes. I use all the tools I listed regularly.

Autocompletion: YouCompleteMe + racer + racerd

Source formatting: rust.vim + rustfmt

Automatic building: https://github.com/passcod/cargo-watch

Error display: tmux, terminator or iTerm2 split planes

Rust has pretty good tool support in vim and Atom, for example (can't speak for the rest). We don't have stellar IDE support yet, but it's on the to-do list: https://www.rust-lang.org/ides.html

Personally, I don't miss IDEs. I like the approach of small, single-purpose, composable command-line utilities more.

It is Rust[1]:

> So, in the middle of this two-and-half-year project, they switched to Rust on the Diskotech machines. And that’s what Dropbox is now pushing into its data centers.

See https://www.reddit.com/r/rust/comments/4adabk/the_epic_story... for more information.

[1]: https://www.rust-lang.org/

What good will an encrypted home folder do if your computer gets compromised? It protects against offline, physical attacks, sure, but I fail to see how it is safe against the myriad of remote attacks there exists.