HN user
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.
Only if you're using Go's native GC as the Lua VM's GC, which isn't the only option.
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.
A lot of it is described in https://www.typescriptlang.org/docs/handbook/type-compatibil...
More examples are on https://github.com/Microsoft/TypeScript/wiki/FAQ
And the slides: http://tinyclouds.org/jsconf2018.pdf
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.
What language / framework / technology stack would you use to make this?
That's what the upvote button is for.
"Much more effort"? Right now it implements a library and a language on top of that. Making it just be a library would cut the work in half.
Yeah I opened the page kind of hoping for something GraphQL. Scraping libs are cool but I have absolutely no idea why this is at the top of Hacker News. It's not declarative, it's unnecessarily a language instead of just a library, the only thing it has that HN would love is that it's written in Go and it's kind of an esoteric niche. Is that really all it takes?
Why is this a language instead of a library on top of an existing language?
Here's what it would look like as a JavaScript (Node.js or browser) library:
let g = getDocument("https://www.google.com/", true);
g.input('input[name="q"]', "ferret");
g.click('input[name="btnK"]');
g.waitNavigation();
let result = g.elements('.g').map(({
title: result.element('h3 > a'),
description: result.element('.st'),
url: result.element('cite')
}));
return result.filter(i => i.title !== null);More styling options: you can use Sass and CSS Modules out of the box.
This is what I'm most excited about. Emotion is great but I've heard a lot of great things about CSS Modules, just haven't gotten around to trying them out yet because it's been so complicated to do. I'll definitely be giving it a try now.
TypeScript is fantastic for its IDE support and instant feedback but I'm waiting for the day it's built into CRA as a first class citizen. Sounds like that day will be soon though maybe even this year.
I think it looks way worse to just let it limp along and slowly die. Fail fast, learn your lesson, and move on.
The benefit of limping along and dying slowly is that it can be relatively quiet and uneventful, and at least the project dies with the appearance of dignity, even though it's actually the opposite. Investors applaud "sticking it out" even though the engineers knew it was dead for years. Review sites write poignant eulogies, instead of writing angry rants which they would do if it was cut short.
The thing about software (and probably most kinds of products) is that there's always someone who relies on it, no matter how dumb of an idea the product is, and usually that group is larger than you expect or seems reasonable. Those people are often the ones who yell the loudest when you inconvenience them, which is why Apple has to pander to them by torturing macOS Server to death instead of euthanizing it.
They are APPLE, they have ridiculous cash.
They have always acted like a start-up that's strapped for cash. I've known many Apple employees and it's just been part of the culture, that if you work at Apple, you're going to wear many hats and they're going to utilize every second of yours to 200%. It was especially so this in the days of Jobs, and I doubt it's changed much in the past decade.
1) It probably makes them at least a noticeable percentage of revenue, if not much, so that cutting it out completely would maybe cut funding for a dozen employees. They'll need to dwindle sales down first, probably by deprecating it, so that they can justify the cut internally.
2) Even if they're backpedalling on the idea of macOS as a server and pushing for migrating to open source tools, they don't want to openly admit this, that always looks bad and unprofessional.
3) They're probably phasing it out slowly and in the next release or two they will probably deprecate it, and remove it completely from MAS in the next major macOS update.
4) They'll want to wait until they can play up their contribution and downplays that they were on the wrong side of history: "We're deprecating macOS Server, which has been a boon and a huge innovation in this space for 20 years, and helped $N millions of customers, but at this point the open source community has finally caught up to our quality."
5) At that point, the remaining useful features will be integrated into macOS proper for free, and they'll tout how they're benefiting everyone by doing this and simplifying everyone's workflow and saving everyone money.
One of my favorite phrases is “a man convinced against his will is of the same opinion still” because it reminds me of the ever-useful principle that if someone has personal (and maybe even irrational) reasons to keep believing something they shouldn’t, like that they have a good chance at winning the lottery this time (no they don’t) and finally get out of the poverty that’s haunted them for decades, or that bitcoin is finally their ticket to entrepreneurial independence (probably not), or that the foreign prince really does want to send them money and all they need to do is buy iTunes gift cards and send him the numbers over the phone, no amount of facts are going to change their minds.