egorelik

I came to basically the same conclusion when I purchased some years back. It seemed to me then that even in the ostensibly smaller mount formats, all the manufacturers were chasing larger bodies and lenses, and reserving all the upscale features in those. I think trends have recently convinced manufacturers that compact bodies are "cool", but I'm still waiting for more compact lens options. I ended up just making due with a large body and carefully managing how I travel with lenses.

I had some interest in the first Sigma FP, but my impression is that it was getting used mostly in highly modular video setups, not so much to save space.

I think there is a crowd, maybe less common than the others, that just want less warts. I can understand that, though I'm not sure the usual dialects that get thrown around are much better.

What I don't understand is wanting to replace elisp with a mainstream scripting language. None of them are really functional-style languages; it's just a completely different world.

(Non-scripting languages are a different story, but fundamentally a different use case.)

To each their own, but I don't really understand the sheer hatred elisp puts in some people. As far as scripting languages go, it's pretty good. I haven't seen a scripting language alternative I'd really prefer for this - maybe Clojure or some other modernized lisp.

I did - I first came to emacs during my lisp phase. I didn't stay with lisp, but I did stay with functional programming, and in those days emacs was the best environment for a number of functional programming languages (maybe still is).

This is how I justify not switching back to vanilla, despite not really being an evil user. Doom's module system is really great for organizing a config.

A common thread I see in this, and other articles of its kind, is that rarely do they come out and say what kind of project they are working on, leaving the headline to sound generically applicable. I can make some guesses, given the emphasis on async, that they contrast with Go, and the mention of systems programming as an exception. But after enough of these, one would get the impression that Rust is primarily a backend language, competing with other backend languages, that happens to also be good for systems. I'm not sure that is even the use case driving corporate adoption.

Nearly 10 years of experience at Microsoft, I've been looking for a remote position for almost a year.

Even just finding appropriate openings has been next to impossible. Every company seems to be looking for either a generalist (lots of full-stack) or a senior in an exact specialized bucket and stack. My role at Microsoft was a sort of specialized databases/compilers/functional programming hybrid, but without clear buzzwords no one seems interested. What was once a frequent stream of corporate recruiter messages dried up a little over a year ago too.

My suspicion is that things are a lot better for non-remote positions in the usual hubs.

Similar but not exactly the same as named impls, I'd really like to see a language handle this by separating implementing a trait from making a particular existing implementation the implicit default. Orphan rules can apply to the latter, but can be overriden in a local scope by any choice of implementation.

This is largely based on a paper I read a long time ago on how one might build a typeclass/trait system on top of an ML-style module system. But, I suspect such a setup can be beneficial even without the full module system.

Rust opened the door to innovation in the low-level languages space, but as long as it is already the most theoretically advanced practical language there, it will always attract the audience that actually wants to push it further. I don't know if there is a way to satisfy both audiences.

As an idea, what about allowing the 24 hours to be bypassed using adb (edit: bypass to allow indefinitely, not just install a single app)?

I understand there is some problem trying to be solved here, but honestly this is still quite frustrating for legitimate uses. If this is the direction that computing is moving, I'd really rather there were separate products available for power users/devs that reflected our different usage.

Back when I still thought all headphones were basically the same, I was writing some music and I could not understand why the cello lines sounded so much louder than the violin lines at the same dynamic. It was only years later that I found out that mainstream headphones are tuned to boost the bass, which is supposedly the mainstream taste.

If your tastes in music are not mainstream (and mine definitely is not), mainstream headphones will ruin your music more than you realize - for years I just thought that was how recorded music is supposed to sound, and it wasn't very good. Trying a neutrally-tuned headphone can change your (musical) life. Unfortunately, very few wireless headphones are tuned that way.

Edit: Part of why I never looked into it sooner, I had heard so much about "audiophile snake oil" over the years, I thought that was all there was. That exists, but there plenty of headphones marketed to "audiophiles" that are legitimate.

I don't remember where I read it, but I think Rust cited Cyclone as an influence, a variation of C with "region-based" memory management - more or less the literature name for "lifetimes". I think Rust may be the first to use it directly for stack variables, however.

Early on in my computing life, I discovered TeXmacs as a user interface for a Computer Algebra System I had been playing with called Axiom. Ironically, this was before I had ever even heard of either TeX or Emacs! It seemed like a cool piece of software, but when I later learned LaTeX I discovered I prefer non-WYSIWYG for everything but lecture notes. Still, in the years since I've recognized that this setup, combining a math engine with a rich display interface, was an early version of what would later be popularized as Notebooks.

I tried that too - it works great for large files, but still chokes on large numbers of files. Which, when I'm transferring photos, is usually the case.