nsm

My partner and I made a Sudoku explainer [1] for my nephews using this. It was a really good toolkit once we wrapped our head around React.

[1]: https://sudoku.nikhilism.com/

I have been using Pharo Smalltalk to solve Advent of Code this year and it’s been a really fun experience! I wish I could use Smalltalk more places, particularly because of the interactive development and the visualization toolkits. Something like PetitParser2 made several of the AoC challenges really easy because if just write a full parser instead of regex or hand parsing.

This is my favorite paper now for 2 years in a row :)

Seconded. This notion of "stacked diffs" is extremely powerful and I miss review systems that lack it. Currently using it for years now in Phabricator by following https://medium.com/@kurtisnusbaum/stacked-diffs-keeping-phab...

I agree. Also, there are certain things that simply cannot be cooked on non-gas because they require the food to be cooked directly on the flame. For example Indian rotis - https://youtu.be/ZckBv7JR__0?t=241 - need to go directly on the gas for a few seconds. Until there is a viable solution to that, I don't see Indians (and by extension, an Indian like me who were overjoyed to find a rental unit in the US that had a gas stove!) switching away from gas any time soon. FWIW, ventilation is generally excellent in tropical countries (above a certain standard of living) because the warm weather means large windows and exhaust fans/vents are very common. I'd like to see an experiment controlling for that.

I believe it is https://news.ycombinator.com/item?id=25178437 and the language discussed is Koka https://koka-lang.github.io/koka/doc/manual.html#sec-effect-...

This seems like a great use case for a chromebook. Have you looked into that? It seems like the Apple premium may not be worth it. You get long battery life, a very slimmed down machine that can run a browser and a terminal, and they are just as slim as a Air + much cheaper.

Yes, but the bundled JRE is slimmed down, to the point where, last I checked, the bazel standalone binary is ~50Mb.

This is a lovely overview of a software developer using Talon day to day - https://www.deconstructconf.com/2019/emily-shea-voice-driven...

Sure! Yet, (as I mentioned in a sibling comment) living in a beautiful place with really clean air where one can be outside 11 months of the year is way better than most of the world, so I find this tendency to go "OMG everything is now broken" to be an exaggeration that detracts from the continued value the Bay Area offers.

I never implied that one shouldn't take the necessary precautions that you mentioned (respirators, filters) _during_ that month and stay indoors. I am merely stating that "Now we have COVID which means you want to be outside, but fire smoke that you shouldn't breath, so you want to be inside." is a false dichotomy 11 months of the year in the Bay Area, which is not the case for a lot of other places.

Coming from a country where the air quality is bad 365 days a year, I appreciate what is possible here, and cannot empathize with this tendency to exaggerate the situation.

“Making is show business now” https://alexdanco.com/2020/10/08/making-is-show-business-now...

Or we could incentivize people not to live in places with wildfire risk by NOT offering insurance (with some sort of graded phase-out for people already living there).

I think this is hyperbole for the majority of people who do not have existing respiratory or other health conditions.

Air quality in SF proper was only bad (by which I mean Unhealthy for Sensitive Groups or above) for roughly a month this year. That certainly doesn't warrant having HEPA filters and P100 masks now in October/November (again, for most people).

What is the advantage of this over the more popular embedded solution which is AFAICT Qt? It was quickly glossed over in the slides without any explanation.

I guess one is Dart is a safer language than C++.

The ninja author has a (relatively) recent blog post about design decisions and lessons learned:

* The success and failure of ninja http://neugierig.org/software/blog/2020/05/ninja.html

- Easy build system. Must be parallel, saturate all cores, and handle distributed builds as a built-in first-class feature. Should be able to produce static binaries or dynamically linked binaries. Should be able to consume binary dependencies (that means a stable ABI).

Rust can actually be built with Bazel. The tooling an ecosystem for doing that is nowhere as good as Cargo and I really wish the Rust team would focus more on supporting other build systems as first class (i.e. not having half the conventions for packages being set by Cargo - things like build.rs output syntax, the various environment variables), since they bring a lot of mature tooling and performance to the table.

Gecko, which is the rendering engine used by Firefox, has existed for longer than Blink/Webkit (powering Electron). It also supported a UI toolkit (described in XML and a wrapper on Gtk etc.) called XUL [1]. I think OP is talking about this. Mozilla never tried to make it easy to use Gecko (plus the Spidermonkey JS engine) as a re-usable library outside Firefox, making something like Electron really difficult to do. On the other hand, Blink is a lot easier to integrate, which is why Electron exists (as a thin wrapper over Blink+V8).

[1]: https://en.wikipedia.org/wiki/XUL

Thank you for this report. I've passed on the information to the right team and they are looking into it.

This is an excellent point. I know someone who is having a really hard time finding jobs because they just got out of school, but there are hardly any entry-level positions and the ones present are highly contested. They must have applied to >200 places at this point. This is in a non-software, but STEM field.

There is this entertaining series called Houyhnhnm Computing that imagines computing invented by a different species.

https://ngnghm.github.io/index.html

To me WASM is interesting because it provides a way to distribute _non-JavaScript_ applications that _already exists_ over an easy to access platform that is the web browser. It provides a much simpler target than transpiling to JS.

For example, I'd really like to see interactive Smalltalk environments like Pharo be available as WASM websites instead of a separate VM. They already implement their own rendering stack within a Window, so they could switch to WebGL/Canvas and not have to even interact with the DOM directly. (That may not be the best long-term solution, I don't know enough to decide, but it is definitely a good short term solution than not doing it at all).

> We want a unified good build system for rust, not a ridiculous mess of difference package managers and build systems like in some other language ecosystems. Sometimes, conformity is a better approach, and I would be deeply saddened to see rust go that way.

I would like to disagree on this. I would prefer to see the Rust ecosystem play better with other build systems, instead of requiring all Rust to use Cargo. This becomes important when you are using Rust as part of a larger, multi-language code base. At my day job, we have Rust, Python and Typescript, and we use Bazel for much of the build, getting a bunch of advantages that Bazel brings to the table - remote caching, being able to query the dependency graph, selective testing and so on. These latter are not available in cargo, and would be significant work to re-implement infrastructure based on querying cargo instead of querying bazel.

I think there are 3 different things that Cargo tries to do, which would be better of with strong (and well documented) boundaries between them, so that users could mix and match each of these.

1. Compiling a crate - This is usually one rustc call. I'd venture saying that build.rs files are another layer, but I haven't thought about it enough. It is pretty common in Bazel-land to have build.rs wrapped in a `rust_binary` that is a dependency for the crate itself (usually `rust_library`). This is the easiest to plug into other build systems. 2. Compiling a set of crates/packages - Assuming a system where all the crates are on-disk, Cargo does the job of invoking rustc correctly with the dependencies passed and the right set of features selected. For Bazel, this is what rules_rust implements. The thing is, rules_rust has to figure this out by inspection of Cargo, instead of being able to rely on editions or compiler versions. (FYI, I've never used rules_rust. We have our own internal rules for Rust and we had to figure out things by inspection. Particularly Cargo specific environment variables that are not a part of the Rust language/stdlib, but are assumed to exist by libraries). 3. Package management - i.e. how to get dependencies from the network/someplace else onto disk. I'd suspect this is one place most large orgs would prefer not to rely on Cargo, because it necessarily locks them into some kind of delivery mechanism that is specific to the ecosystem, instead of having a dumb file server. i.e. we would need one for npm/yarn, one for pypi and so on, where each of these frontends know how to go from the "language package name" to the file on disk. I much prefer Bazel here where external dependencies are specified just by HTTP URLs and a sha256 hash to verify contents.

I'm almost _not_ on board with each language building their own compiler driver and package manager, because they end up duplicating so much work - some kind of caching mechanism, some kind of toolchain mechanism, some kind of resolver mechanism and so on...

As someone not at all involved in web development, if I wanted to learn CSS properly, with all the new flexbox/grid support instead of fighting with margins etc, what are some good recommendations? Like say I don't care about browsers older than a year ago and I only want to use the sane parts of CSS.

Say you want to tell your mom once you safely reach school (via public transport). But you don't actually want to spend the money on a call or text (India did not have "unlimited text", at least when I was growing up there). So your mom and you agree on a protocol that "one missed call means I reached safely". Now you just call her and disconnect immediately. Message received.

If that is the intent behind such decisions, a more reasonable (and not punitive) response is to give a couple of years notice to universities (let them wind down operations) and allow students already enrolled to finish their education. Not “Go home right now or you will be deported, and forget about the full tuition you paid.”

If you were actually someone who has been through the US immigration process, your lack of empathy is appalling.

One can do some good (even for selfish reasons) and it can be commendable. One isn’t obliged to solve the entire problem.

https://blog.jaibot.com/the-copenhagen-interpretation-of-eth...

Jonathan Haidt's org has a nicely illustrated, highly abridged version called "All Minus One" - https://heterodoxacademy.org/library/all-minus-one/

The reality is that the US government has done NO meaningful progress on immigration reform to guarantee a path to citizenship for skilled people. This leaves H1B as the only option and now that is gone too, but only due to executive order. I find it hard to believe there will be any meaningful reform under any administration. Particularly until they can get out of this habit of clumping all kinds of immigration (legal and illegal, skilled and unskilled) into one bill, so that nobody can agree on anything.