egorelik

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.

I've used AI for a number of Emacs-related utilities and configs. Just today I created a script to reproduce the particular combination of MSYS2 packages I use for my newer on Windows setup - the hard part being to get native comp working. Small, but it's the sort of rarely used convenience I wouldn't have written up in the past.

https://github.com/egorelik93/Doom-Emacs-Config/blob/master/...

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.

I too find the phone market, especially in the United States, has outright abandoned users like me. About a year ago I rushed to buy what seems to have been the last flagship model sold in the United States to have micro SD card support (an Xperia 1V), as soon as I saw stocks were dwindling. Now there are none left, and while I should be good for a few years, I fret over what I will do next time.

Just the other idea, I tried transferring a large number of photos from phone to PC with a cable, just to see how bad it would be without a card. It was so slow I eventually gave up (not to mention the timestamps were messed up). I have no idea how anyone manages this way.

N pretty much is "arbitrary-length information theory". As soon as you leave the realm of the finite, you end up with N. I'm not convinced that any alien civilization could get very far mathematically or computationally without reinventing N somewhere, even if unintentionally (e.g, how does one state the halting problem).

I'd agree with that for practical purposes, but sometimes the external perspective can be enlightening philosophically.

In this case, to actually prove the statement internally that "not every real number is computable", you'd need some non-constructive principle (usually added to the logical system rather than the theory itself). But, the absence of that proof doesn't make its negation provable either ("every real number is computable"). While some schools of constructivism want the negation, others prefer to live in the ambiguity.

I am talking about constructivism, but that's not entirely the same as saying the reals are not uncountable. One of the harder things to grasp one's head around in logic is that there is a difference between, so to speak, what a theory thinks is true vs. what is actually true in a model of that theory. It is entirely possible to have a countable model of a theory that thinks it is uncountable. (In fact, there is a theorem that countable models of first order theories always exist, though it requires the Axiom of Choice).

The idea is we can't actually prove a non-computable real number exists without purposefully having axioms that allow for deriving non-computable things. (We can't prove they don't exist either, without making some strong assumptions).

I believe the author does talk about the first-order model theoretic perspective at one point, but yes, I was referring to that notion.

The author mentioned that the theory of the complex field is categorical, but I didn't see them directly mention that the theory of the real field isn't - for every cardinal there are many models of the real field of that size. My own, far less qualified, interpretation, is that even if the complex field is just a convenient tool for organizing information, for algebraic purposes it is as safe an abstraction as we could really hope for - and actually much more so than the real field.

I went into this expecting it to be a criticism in the context of low-level systems, and was a bit surprised when it ended up being about distributed. The mismatch the author is describing, I think, is not really about functional programmers so much as everyone not working directly on modern distributed or web software. For being upfront about all the ways distributed programming is different, this is actually one of the best intros I have seen for the non-distributed programmer on what distributed programming is really like.

I still want to believe that future programming languages will be capable of tackling these issues, but exploring the design space will require being cognizant of those issues in the first place.

As far as I'm aware, Rust's trait system is more closely related to Haskell's type class system than to actual object-oriented programming. As a type class system, it is fine; it is a different mindset than classic OOP. Rust happens to also use this same system for something more closely resembling traditional objects, but this is much more restricted than either.

The only conclusion I can draw from this is that some engineers are not great at arguing the merits and challenges of a programming language. GC vs non-GC should be one of the first and most straightforward decisions made when picking a language. It's hard to tell in this situation given that there are no concrete examples of what the arguments were, but if one is seriously considering Go for a domain, then they don't actually need the complexity a non-GC language brings.

If anything, maybe this says there is room for a Rust-like GC'd language.

Sometimes, and for some people, the right language can actually simplify problems and hide complexity that isn't immediately necessary to the problem at hand. The whole idea is to abstract away models and worry about them separately. This is one of the motivations for the various synthetic theories that are getting researched in the last several years - the one mentioned here happens to be for Category Theory.

This doesn't work for everyone though; some people find it easier to stay grounded in specific models.

Skepticism of a ZFC axiom in particular could just be in terms of its standard status. I don't think anyone debates that ZFC in a particular logic doesn't imply this or that, but people can get into philosophical questions about whether it is the right foundation. There are also purely mathematical reasons to care - an extra axiom may allow you to produce more useful math, but it also potentially blocks you from other interesting math by keeping you out of models where, e.g., Choice is false.

    Location: USA
    Remote: Yes
    Willing to relocate: No
    Technologies: C#, Rust, Haskell, C, Functional Programming, SQL, Parquet, Git, OData, some C++, limited Python. Started playing with Datafusion.
    Resume/CV: Upon request
    Email: v5d72jvtu at mozmail dot com
    LinkedIn: https://www.linkedin.com/in/eric-gorelik-45662312b/ (preferred)

Hi HN! I'm Eric, a senior software engineer who has worked in the intersection of the databases and compilers spaces. I have nearly 10 years experience at Microsoft as a developer on a partially-lazy functional query language. Before that, I concentrated heavily on compilers, programming language theory, and formal logic in college (with some OS kernel and computer algebra stuff on top), and I remain passionate about them. In the years since I've gained knowledge of modern OLAP database internals. Recently I've worked on Parquet integration and optimization in this query language and Microsoft more broadly.

On the side I experiment with programming language design, especially with applying math-inspired ideas to low-level programming. I'm looking for a fully-remote position. If any of this sounds interesting, please reach out.