That's a good way to put it, and yeah I would agree that's how I like to use errors: give me the details I ask for and let me ignore the ones I don't care about. Sometimes an "error" isn't really an error, and at those times exceptions are overkill. Sometimes an error really is an error and I need to let the user know something went wrong, give them enough details to let them fix it and wait for them to try again.
If you're writing a command line utility that tries to load a config file and falls back on defaults if it's not found, you may try to load it and just ignore any error, only caring that it either returns a path if found or null if you should use default values.
Without taking sides on the issue, these are purposeful trade-offs that the Go team makes. They are trying to avoid bloating the language and making it too difficult for them to add optimizations or other features. And I think they would argue that it makes ignoring errors harder, since you have to intentionally discard the error value when it was given to you, which takes conscious effort, rather than omitting it from the code completely like other languages let you.
I think the core distinction is business-centric conferences vs developer-centric conferences. You've entirely named the former. Those are geared towards using platforms, and while developers are welcome, they aren't the entirety of the target audience, business professionals (eg MBAs) are just as first-class at those. But Ruby and Python and Swift conferences are going to entirely be geared towards developers.
I think the hammer analogy works better as conferences for building houses (business conferences) vs power tools (developer conferences) vs hand tools (no conferences), the distinction being how quickly can you get to a finished house. A power tool is something that can make houses quickly. A hand tool can be used quickly and efficiently by someone very experienced with them, but power tools can be used by almost anyone.
There seems to be a lot of influence between editors which to me is the most interesting part of all of this. Just looking at TKE's screenshots, it resembles VS Code to a not-insignificant degree, and VS Code and Atom both seem to have been inspired graphically by Light Table, and all of these as well as Alpha have a programmability that's heavily inspired by Emacs, although Alpha's GUI is closer to TextMate which was influenced by BB Edit, and the history of editors is something I'd love to see someone with more knowledge of the history do a more comprehensive write-up of it.
True, but anecdotal data are also useful. I came to this thread to see what a bunch of other deep thinkers think about standing desks and if they have any stories to tell. For my part, I made one some years ago, and have found it to be invaluable, not because of the standing, but because it's uncomfortable to stand but not distractingly so, which keeps me moving around a bit and shifting positions and taking short breaks while I work. Although the same is true about sitting down at a desk, but it's easier to do these with a standing desk which encourages me to do them more often than when I'm sitting.
Go was originally intended as a systems level language, suitable for writing extremely efficient servers, dealing directly with raw bytes where needed, therefore enabling writing code at both high and low levels. VMs typically take advantage of the lowest level of code that their language supports to be as efficient as possible. There's no reason Go code can't be as fast as C++ code with enough time for optimizations, and there's no reason a VM written in Go has to be slower than any other low-level program written in Go.
Nothing necessarily surprising about this. Yes Go is made by Google, but not by all of Google, just like this project isn't necessarily a first-class Microsoft project (although it might be). And Microsoft has contributed significant amounts of open source in the past few years. Lua is also a great language to support first-class, as its popularity is increasing more each year due to its ease of embedding.
I know you're not necessarily looking for specific advice to this one problem, and I agree and would rather pay for software than be the product, but since email is the topic, have you looked into FastMail? You pay for it, there's no ads, and they don't sell your info.
> Note: This is not an officially supported Google product at this time.
Why is that? Is it kind of like the other project that was here recently, where it was created at FB but now independently maintained and not a corporate sponsored project (anymore)? Or is it deprecated and no longer recommended?
That's not an inherent limitation of the language though. There's nothing stopping a server-side implementation from adding threads as a first-class feature and breaking away from the spec. Ideally it would do so in a way that's backwards compatible with libraries that assume they're on the same thread as themselves, but that isn't infeasible.
This is an excellent hindsight-2020 project, and the concept is overall an improvement on Node, but I'm afraid the ship has sailed and Node's momentum is too high to stop. Not that mainstream usage was ever its goal, it was basically a proof of concept for Ryan Dahl to demonstrate how he would do things differently if he could start over, and that yes, it would be demonstrably better than Node. On one hand I wish TypeScript got more love, but on the other hand its inherent unsoundness kind of makes me want something like ReasonML[1] to win out in the long term instead.
Well shit. Yeah usually I read the article first but the title got me so excited that I wrote the comment because that topic really fascinates me. Oh well. Thanks for pointing it out.
I'm intrigued by this idea of random-socialization online. Obviously the sites like this have thus far catered more towards sexual content, but I feel like there's huge potential for online streaming socialization that Twitch and Discord haven't fully tapped. I can't put my finger on what, but there have been nights I just want to hop online and meet random strangers to talk about common interests about. Kind of like going to a bar to meet people, but with a higher chance that they'll be interested in the same things as you, so a cross between going to a bar and coming to HN to discuss interesting things.
Nonsense. JavaScript is a general programming language that's suitable for many different kinds of environments. It just so happens to have started in the browser, but it could just as easily be embedded like Lua, or ran on the server like Python, or be used for shell scripting like Perl, and even used in embedded devices like mruby.
I immediately disabled the “smart completion”. It was wrong 100% of the time so far, and it’s just going to ruin my train of thought, or worse, train me to say what it thinks I should say.
They’re still mainly bundlers for now, such as webpack. But browsers are slowly adopting first class modules which has already been solidified by the spec afaik.