A community-driven port of Emacs to Rust(github.com)

230 pointsby dangom7 tahun yang lalu143 comments

A community-driven port of Emacs to Rust

https://github.com/remacs/remacs

16 comments

melling7 tahun yang lalu

Much of Emacs is written in its own version of Lisp. There has been some effort to use Scheme, using GNU Guile

https://www.emacswiki.org/emacs/GuileEmacs

Emacs with a better Lisp option would be a big improvement. With a faster Lisp, perhaps less of Emacs would need to be written in C/Rust.

girzel7 tahun yang lalu

What would make most sense is just to have it Lisp all the way down. SBCL, top to bottom!

sjm-yc-acct7 tahun yang lalu

There have been some efforts like this (etc.) for Emacs on CL:

https://common-lisp.net/project/phemlock/

I have never been able to get one to work, though.

MIT Scheme also has an Emacs 18 compatible editor called edwin written in Scheme.

rjsw7 tahun yang lalu

Hemlock was written as part of CMUCL and is still supplied with it. The portable version is also used as the editor in Clozure CL.

What didn't work for you ?

sjm-yc-acct7 tahun yang lalu

I tried Portable Hemlock from Quicklisp, and IIRC it would not install from the repos.

On Clozure, the IDE with Hemlock only runs on OS X--I use Linux.

The one in CMUCL might work, but I haven't tried it because they only have 32 bit support for x86.

I wasn't trying to be dismissive--I would really like to run Emacs on CL!

rjsw7 tahun yang lalu

CMUCL will run on 64-bit Linux, that is how it is built. There would obviously be a smaller limit to file sizes than if Hemlock were running in a 64-bit Lisp.

na857 tahun yang lalu

Is there a serious project working on this? I'd contribute to it.

molteanu7 tahun yang lalu

I'm in. Where do I put the money?

aerique7 tahun yang lalu

I would also be willing to donate although the project would not be very viable. It's a lot of work, Common Lisp is not a currently fashionable language like Rust, it would not have support from RMS.

It would probably die out soon. XEmacs is one of the longest living Emacs forks and even that is dead(ish).

Still, I'd put up some money for this.

(This post was written inside EXWM ;-)

na857 tahun yang lalu

>it would not have support from RMS.

Is this something we care about? RMS doesn't own lisp-based text editors.

aerique7 tahun yang lalu

I don't care but many follow him[1] which might take a big bite out of your potential userbase.

[1] Not without reason since his foresight has been correct wrt privacy, civil rights, etc.

sjm-yc-acct7 tahun yang lalu

I would work on it for money. My company's website is listed on my HN profile--there is contact info on the website.

z3phyr7 tahun yang lalu

That should be the goal. To please rms, one can always use a GPL language implementation too..

cnasc7 tahun yang lalu

Minor correction: guile Emacs doesn’t replace Emacs lisp with scheme. It just uses guile as a backend for Emacs lisp.

microcolonel7 tahun yang lalu

Minor addition, Guile Emacs does allow you to use Scheme in addition to elisp, AFAIK.

armitron7 tahun yang lalu

Minor addition, Guile Emacs is a dead project since not a single person from the core Emacs development group cares enough about it to work on it.

Emacs Lisp is getting better all the time feature-wise, is portable to all main operating systems (good luck running Guile on Windows and macOS without issues) has enormous user base and is rock solid.

na857 tahun yang lalu

Can't speak for Windows but Guile runs on my mac just fine.

Ericson23147 tahun yang lalu

Yeah I feel like guile-emacs, then rust-guile, is the proper migration path.

girzel7 tahun yang lalu

> Code written in Rust easily interoperates with C. This means we can port to Rust incrementally, and having a working Emacs at each step of the process.

This seems really important, and crucial to preventing the project from getting stuck at the pie-in-the-sky stage. Start it going, and dog-food it as it comes!

smt887 tahun yang lalu

Partial/staged rewrites have become the only way to rewrite many mature projects.

Facebook (PHP/Hack), Firefox (whatever/Rust), and large web projects (JS/TypeScript) could only be rewritten piecemeal.

caymanjim7 tahun yang lalu

Why? Other than an academic exercise, what's the point? One could make plenty of arguments for why Rust is a better language than C, but...if it ain't broke, etc. This seems like an enormous exercise with little if any payoff, and unless the core Emacs community decides to jump on board, it's just a pointless fracturing.

dmitriid7 tahun yang lalu

Oh. Emacs is broken. For example:

“Internally, Emacs still belives it’s a text program, and we pretend Xt is a text terminal, and we pretend GTK is an Xt toolkit.” [1]

If this fork removes all the legacy cruft and hacks, it’s only for the better.

[1] https://m.facebook.com/notes/daniel-colascione/buttery-smoot...

TeMPOraL7 tahun yang lalu

I don't have an opinion on the way it does that, but the fact that it does think/work it's a text program is actually a feature, not a bug. Something like 99% of built-in features and 95% of features added by plugins work identically in terminal frames over SSH.

I fear if Emacs was remade with graphics at the forefront and text as a secondary concern, we'd lose a lot of interoperability this "text program" thinking brings to the table. Being able to work with an UI in a way you would with text files - jumping, copy-pasting, editing the UI itself, all with the exact same shortcuts and conveniences you use for programming - is incredibly powerful and something not really replicated elsewhere. I mean, number one complaint against TUIs and GUIs is that the data is locked inside, and you can't easily take it out and send elsewhere. With Emacs UIs, it's not true - if need be, you can select, copy and paste the whole thing, UI included, and it looks good in a text file and can be operated on programmatically.

--

Further improving performance of elisp and enabling true multithreading/async: that would be a huge breath of fresh air in Emacs.

dmitriid7 tahun yang lalu

Which part of ”we have to pretend to be a deprecated system that pretends to be an even more deprecated system that pretends to be an obsolete system to prevent Emacs from flickering” is a feature?

TeMPOraL7 tahun yang lalu

That is an implementation detail. The feature is "witness the firepower of this fully armed and operational battle station/editor, of which 99% works and looks the same both in GUI and terminal, at zero extra effort from feature developers". Whether or not the implementation is truly necessary to achieve the feature, that I don't know.

dmitriid7 tahun yang lalu

It’s not an implementation detail. It’s decades of technical debt, and it’s very strange to see it defended.

When a simple task of making a program not flicker (a solved, well understood and fairly trivial problem) requires quite a sizable effort, it’s no longer just an “implementation detail”.

LOL at people decrying the bloat and inefficiency of Electron apps and calling this a perfect program with just implementation details:

— start quote —

GNU Emacs is an old-school C program emulating a 1980s Symbolics Lisp Machine emulating an old-fashioned Motif-style Xt toolkit emulating a 1970s text terminal emulating a 1960s teletype. Compiling Emacs is a challenge. Adding modern rendering features to the redisplay engine is a miracle.

— end quote —

barrkel7 tahun yang lalu

Don't focus in the mechanism. People aren't defending the mechanism. They are defending the benefit, which is currently a side effect of the mechanism: feature invariance with respect to render target, whether GUI or terminal.

My own use is about 50:50 of each. Only a few things don't work the same way in the terminal and that's extremely valuable.

TeMPOraL7 tahun yang lalu

Let me rephrase my thoughts. I'm not defending this cruft per se. I'll be glad to see it gone iff it doesn't affect the text-orientedness of Emacs UI, as this specific style of text UI is a feature.

bitwize7 tahun yang lalu

No, it's not really. In order to get window toolkit independence, and terminal- or GUI-independence, Emacs pretty much has to pretend to be a deprecated system pretending to be an even more deprecated system pretending to be an obsolete system.

It needs a rewrite with modern tools and frameworks. And it needs to abandon the terminal (the obsolete system) altogether.

tonyarkles7 tahun yang lalu

Up until about a year ago, I used emacs exclusively from a terminal. The only reason I switched was because I usually have a number of tmux sessions open (with multiple “windows” in each one), and I kept losing emacs :). Having it in its own window made it easier to jump back to.

I’ll still often SSH home from a Chromebook and edit remotely. The fact that everything still works exactly the same is awesome. If you want to make an editor that doesn’t support that, you’re welcome to, but it won’t become my editor :)

Tcepsa7 tahun yang lalu

"Now that I've SSH'ed into this system I sure wish I couldn't use Emacs!"

--Nobody, ever

(My point being that I think abandoning the terminal would be a huge loss to many people and therefore a poor decision)

TheCoelacanth7 tahun yang lalu

Why would you SSH into a system and use Emacs there when you can just have Emacs handle SSH for you[1]? What do you gain by running the whole UI over SSH when you can just send the reads and writes instead? Especially since Emacs might not even be installed on the remote machine.

[1] http://www.gnu.org/software/emacs/manual/html_node/emacs/Rem...

Tcepsa7 tahun yang lalu

Tried again just now to use Remote File access from my Windows desktop to my Linux (Ubuntu) cloud VM. I'm using Helm, and if I do C-x C-f (helm-find-file) and then type /ssh:me@remote: it opens a new buffer called "C:/ssh:me@remote:".

There was a suggestion on a Reddit thread to use Dired instead: C-x d /ssh:me@remote: which I also tried. This appeared to get further but subsequently failed with the error "ssh_askpass: exec(/usr/lib/ssh/ssh-askpass): No such file or directory".

So I figured I'd try launching Emacs from within a Git Bash prompt to see whether that would provide the extra commands it was looking for, and it failed to locate my dotfiles (must have a different $HOME in that context...). However, when I attempted to open a remote file it did actually prompt me for a password! ...but then the LDAP authentication failed after timing out.

I'm out of gumption for now, but hopefully that helps to illustrate why I still want to be able to SSH into a machine and launch Emacs from the terminal.

Tcepsa7 tahun yang lalu

Because I can. I've tried TRAMP a few different times in the past and, for whatever reason, I bounced off of it pretty hard every time. They were long enough ago that I can't remember what went wrong, but I have a pretty deep and lingering feeling of frustration whenever I contemplate giving it another go. Compared to the effort needed for me to shell into the remote machine and start Emacs there, I just haven't bothered.

I think it's great that the capability exists and that others find value in it; it's just not for me (or maybe vice versa). One of the great things about Emacs is that it can still work for both sets of people: folks who like TRAMP and folks who like to SSH in and run it locally.

TeMPOraL7 tahun yang lalu

Because it's already there?

I routinely SSH to my home desktop, where an instance of Emacs is always running, to work from e.g. a bus, or a queue to the doctors', etc. Since I'm normally working on my desktop, which runs GUI Emacs, when I SSH in I have all my files and processes opened as I left them, and I can pick up working via interface that's 99% indistinguishable, sans the smaller screen size.

[deleted]7 tahun yang lalu

Latteland7 tahun yang lalu

It's actually important that emacs is a text program and also has a gui version. All the time I use a program on the command line that needs me to edit something, so it pops up a textmode (vt100 ui forever) emacs that I can edit a file in. Sometimes in other contexts this can happen where it's an xwindows gui. When I'm on a windows machine I can do either also.

dmitriid7 tahun yang lalu

Ok. Let’s say we remove this: ”we have to pretend to be a deprecated system that pretends to be an even more deprecated system that pretends to be an obsolete system to prevent Emacs from flickering”.

How will it make Emacs not a text program with a GUI component?

Latteland7 tahun yang lalu

I don't care about the implementation (if elisp works the same and the experience is the same), it just needs to be a text mode only editor and a gui editor.

yason7 tahun yang lalu

This fork aims to replace the C parts with Rust. I didn't read they intend to redesign Emacs itself. Emacs is a programming environment so changing such fundamentals would make it a different editor. There are existing apps and libraries that depend on the way Emacs works now.

[deleted]7 tahun yang lalu

tedunangst7 tahun yang lalu

What is it about rust that makes it impossible to pretend Xt is a text terminal?

dmitriid7 tahun yang lalu

Wow. If any program had ”we have to pretend to be a deprecated system that pretends to be an even more deprecated system that pretends to be an obsolete system to prevent Emacs from flickering”, HN would crucify it.

With Emacs? Oh, it’s perfect!

DennisP7 tahun yang lalu

The page mentions some reasons: "Forking is a longstanding tradition in the Emacs community...By forking, we can explore new development approaches. We can use a pull request workflow with integrated CI. We can drop legacy platforms and compilers."

agentultra7 tahun yang lalu

This was my first thought. As a user of remacs I'll never notice any tangible difference to emacs if the remacs folks are doing their job well. At least not for a few more years perhaps.

This may have a payoff for maintainers. If they can convince enough of the core developers to join them or build a large enough community. If their theory is right it's easier to develop and maintain Rust code than C code and if it makes more people happy we may see remacs able to forge ahead with more/better features, faster than upstream emacs.

But from my experience with projects like this it's going to take them a long time to catch up and then someone down the line is going to have to make the decision about whether to break from upstream or to follow it.

m4637 tahun yang lalu

I've always thought that if emacs lisp were replaced with python, I would be very happy.

taeric7 tahun yang lalu

I'd wager there are a fair number of us that are quite glad not to have python as the main language.

I am curious if there are specific things about elisp that you dislike.

m4637 tahun yang lalu

I do not want to throw away emacs, I just think a python port would be enjoyable, for me.

I find python very expressive.

When I work in elisp, I seem to find it cumbersome to do many of the mundane things, like using a local variable, and if/then/else with multiple statments, loops (continue? break?), oo stuff, etc.

a contrived example:

    (let ((foo))
       (if cond
         (progn
           (setq foo 10)
           (bar))
        (progn
           (setq foo 20)
           (baz))))

    if cond:
       foo = 10
       bar()
    else:
       foo = 20
       baz()

To be clear, yes, I know how to do these things, and I've written elisp for many years. Everything I can do in python, I can also do in lisp. It's just that python seems to read and write easily for me.

TeMPOraL7 tahun yang lalu

> When I work in elisp, I seem to find it cumbersome to do many of the mundane things, like using a local variable, and if/then/else with multiple statments, loops (continue? break?), oo stuff, etc.

That's, frankly, because you don't know the language. It doesn't take much to learn it, though, and lisps tend to be similar, so you'll learn a bit of CL and Clojure at the same time :). I would similarly struggle with Python, for a short while at least, if you sat me in front of PythonMacs.

Your example could be rewritten as:

  (let (foo)
    (cond (condition (setq foo 10)
                     (bar))
          (t (setq foo 20)
             (baz))))

... which already looks like Python code, except supports arbitrary number of branches (cond is if/else if/else).

Lisp has a slightly different style of writing than in Python, which yields comparably tight and readable code... and then you can use macros, which Python doesn't have, dynamic binding, which Python doesn't have either (and while a pain most of the time, they're a life-saver in some cases, and the type of code you write for a text editor has lots of those).

Elisp isn't a bad language. It can handle all the stuff Python does and then some. I get the preference for syntax you're already familiar with, but individually, it might be worth it to just bite the bullet and learn some new syntax. If that's your first exposure to Lisp, then it'll be especially rewarding, for all the "code is data is code" and "code that writes code that writes code" enlightenment that comes with it.

m4637 tahun yang lalu

You are correct when you say "Lisp has a slightly different style of writing than in Python"

Maybe I was trying too hard to use "if" as common ground in my contrived example. I generally use if for simple conditions and cond for multiple conditions (python would use elif, and has no case statement).

But in the same vein, your example doesn't look like python, at all :)

The point of my comment is not to put down elisp, but instead to say that the translation of ideas in my head to working code seems to go smoother for me using python than lisp, both reading and writing.

tincholio7 tahun yang lalu

Your example is not necessarily contrived, but it is not very representative, either. Throw in a couple of proper lambdas in there, and suddenly python won't look as nice.

m4637 tahun yang lalu

I do stuff like this all the time:

    mysorted = sorted(mydict, key=lambda t: t['Price'])

but generally I write out functions in python.

taeric7 tahun yang lalu

Fair, "different strokes" and all of that. I'm not going to try and argue you out of the opinion, since, well, we are free to disagree. :)

Not surprisingly, I have not had to maintain large blocks of elisp. I have had to deal with chunks of python from folks, and I just can't find it a language that is pleasant. Certainly not stable. Though, I am probably tainted in the whole python 3 debacle.

m4637 tahun yang lalu

I agree with your take on python 3. I think it created a lot of confusion.

Maintaining someone else's code is always a challenge, no matter what the language.

The only elisp I've maintained are my startup files, ~4000 lines.

I will say that the emacs elisp/C code is really special because you're always a meta-. away from checking out every editor function.

testcross7 tahun yang lalu

This isn't the sortest elisp equivalent, no? I'm not a pro, but this should do the same thing for example.

    (if cond
        (progn
          (setq foo 10)
          (bar))
      (setq foo 20)
      (baz))

qubex7 tahun yang lalu

When did the word ‘porting’ lose its notion of reusing similar code on another architecture and become synonymous with “rewriting in another language”?

This isn't a port at all. It represents a more major bifurcation than does even a traditional ‘fork’. It's very imprecise use of language.

ses19847 tahun yang lalu

Can't port be used to mean both changing platforms or languages?

You have a project. You want to change one thing about it, and as little else as possible. If you're porting to platforms maybe that's pretty easy these days, porting to languages is harder and you'll have to make more incidental changes along the way.

alexozer7 tahun yang lalu

I've taken "porting" to equally mean either. Besides, porting to another language is in a good sense "porting to another platform".

qubex7 tahun yang lalu

That’s why I was very specific in mentioning ‘architecture’ in my original question. What you’re mentioning is more akin to the definition of a platform.

piinbinary7 tahun yang lalu

I just downloaded and built that. I was presently surprised to find that it "just worked." It picked up my .emacs, my color theme, my extensions and all the associated data. The only observable difference between it and real emacs was that it ran significantly slower. Presumably that will go away with time.

Great work!

rcthompson7 tahun yang lalu

I'm surprised there would be a significant speed difference. My understanding is that they're mostly rewriting the C parts in Rust, which shouldn't change the speed much. Maybe byte-compilation is disabled for remacs or something? Or perhaps some debug options are enabled by default?

jaccarmac7 tahun yang lalu

Byte-compilation isn't disabled. The slowness is due to a couple things. First is the bindgen layer between Rust and C slowing down certain calls. Porting so far has been wide rather than deep, so Rust code ends up having to call C sooner rather than later. In addition most of the ported functions have been rewritten in a pretty naive style that doesn't take full advantage of Rust. There was some discussion in Gitter or issues about this a couple weeks back, but I cannot seem to find it tonight. Apologies.

rcthompson7 tahun yang lalu

This is something I've been wondering about. Porting from C to Rust one function at a time sounds nice, but presumably the end result would be a Rust program with an identical program structure to the original C, which as a result doesn't take very much advantage of Rust's features. Is the goal to port all the way to Rust and then refactor to actually make the code Rust-ish?

jaccarmac7 tahun yang lalu

Yep! Even now it's not quite as bad as identical program structure. I mean, the high-level is fairly similar, but even now individual functions can look significantly different.

Emacs' C is already largely written in a high-level, macro-rich style to deal with Lisp objects (tagged pointers). So Rust already gives wins there w.r.t. more explicit types and From/Into impls over macros.

And over the last couple weeks there has been discussion about replacing xml.c with a native Rust backend for XML parsing.

adito7 tahun yang lalu

Is it release build or debug build?

aasasd7 tahun yang lalu

The “Porting Elisp primitive functions” section in the readme is impressive for a passerby. Rust code looks like OOP magic instead of C's straightforward struct-juggling: https://github.com/remacs/remacs/blob/master/README.md#porti...

brians7 tahun yang lalu

Can you expand on that? The rust example looks like pattern matching and dispatch into a standard library. The C looks like some macros and tests, and dispatch into a standard library.

But I’m much more comfortable with ML than with C; What do you see that is magic?

aasasd7 tahun yang lalu

Well, I'm not sure what the “y.atan2(x)” thing is reasoned to be in Rust, but it sure doesn't look like C's manual unboxing and plain function calls. Not magic, I guess―just looks pretty much like good old OOP, which I'm being told it's not.

I suppose the “Same(x)” thing caught me by surprise―dunno, though, if it's built-in magical syntax or again something OOPy: in Python, ‘Some’ would likely be a class implementing a special method ‘__match__’.

steveklabnik7 tahun yang lalu

Method calls are syntax sugar in Rust; it compiles to the same code as atan2(y, x). The only difference is it will auto ref for you in the method style. You can call it either way if you prefer. Those are just regular floats, not objects.

Some is an enum constructor that’s in the prelude, so it’s just automatically imported. It’s a library type, nothing specially built into the language.

oblio7 tahun yang lalu

It's not OOP, it's pattern matching, which is functional more than anything.

The other thing is generics (Option<EmacsDouble>) which is not necessarily OOP either and the option type itself which is functional (https://en.wikipedia.org/wiki/Option_type).

hu37 tahun yang lalu

    "Rust has a fantastic learning curve."

Is this some kind of typo?

gpm7 tahun yang lalu

I doubt it. Rust's learning curve is much better than C/C++ (assuming your target is "reasonably competent at writing code other people would want to use" and not "can make a linked list").

hu37 tahun yang lalu

Easier than C/C++ doesn't mean much and certainly doesn't grant a language "fantastic learning curve" status.

saagarjha7 tahun yang lalu

C isn't really that complicated; it just makes it a lot easier to make mistakes.

roywiggins7 tahun yang lalu

It's way easier to learn to write correct Rust code than correct C code. Correct as in not leaking memory or reading uninitialized memory or segfaulting, which probably everyone who first started writing C spent time wrestling with and learning how to use Valgrind and so on.

saagarjha7 tahun yang lalu

Yes, of course; I'm pretty much of the opinion that it's basically impossible to write correct C code because it's so easy to make mistakes in. However, it is easy to write code that generally works, more so than in Rust, which puts up abstractions designed to prevent every single kind of mistake, some of which you might not even know exist because you've just started learning programming.

Which approach is better? Not sure. But that's a different question.

smt887 tahun yang lalu

> easier to make mistakes

That sounds like a core part of the definition of "steep learning curve"

microcolonel7 tahun yang lalu

It is also easy to make a program that compiles in C, and somewhat easy to make it work in some case from there. The real tough part is learning all the tooling required to do anything complex reliably in C.

Althorion7 tahun yang lalu

I don’t know… I’d rather say that learning curve is more of a journey from ‘I can write code’ through ‘I can write code that compiles’, ‘I can write code that works’, ‘I can write code that works well’ to ‘I can write code that works well and is readable’ and certainly the first few steps are much harder in Rust than in C or even C++, so I’d call that a steeper learning curve.

gpm7 tahun yang lalu

One thing to note is that the claim wasn't "shallower" but "fantastic". A sufficient response to this is that it's "fantastic" because the vertical distance between "can write code that compiles and looks reasonable" to "can write code that is reasonably correct" is small. I doubt you would find many other languages where that area is so small in fact (Idris comes to mind).

I'd also argue though that while the learning curve for rust is initially steeper, it is shallower when you look at the curve up to the point where you want contributors to be. C/C++ has an insanely steep cliff to go from "can write reasonable looking code" to "can write reasonable correct code".

The first argument is in some sense better because it doesn't restrict me to talking about C/C++.

smt887 tahun yang lalu

A few points on that:

- Rust skips (or almost skips) some of those steps. If you can write code that compiles, you can also write code that works. It forces you to be very specific about your intentions, which isn't possible in language with less-thorough type systems and compile-time checks.

- I agree that the curve is steeper at first, but it's arguably impossible to write code that "works well and is readable" in C/C++ (which is why we have Rust in the first place). That makes the latter part of the learning curve an asymptote.

saagarjha7 tahun yang lalu

> Rust skips (or almost skips) some of those steps. If you can write code that compiles, you can also write code that works. It forces you to be very specific about your intentions, which isn't possible in language with less-thorough type systems and compile-time checks.

Forcing new programmers to be specific about intentions they may not even know they are supposed to have doesn't necessarily work.

> I agree that the curve is steeper at first, but it's arguably impossible to write code that "works well and is readable" in C/C++ (which is why we have Rust in the first place). That makes the latter part of the learning curve an asymptote.

I don't agree with your analysis of "works wells and is readable". It's not too to write C code that works well and is readable. Sure, your code might occasionally break–but the point is that it works most of the time. This isn't necessarily a good mindset to have as a software engineer, but with regards to the specific claim that Rust is easier than C: it's not, because it enforces better practices, which is mental overhead and complexity that C doesn't need to deal with.

pzone7 tahun yang lalu

> Forcing new programmers to be specific about intentions they may not even know they are supposed to have doesn't necessarily work.

Rust is not a good language for new programmers. Neither is C for that matter. You shouldn't start learning Rust before you have solid intuitions of programming concepts like ownership, scope and mutability.

rat99887 tahun yang lalu

And thus the steep learning curve.

smt887 tahun yang lalu

It doesn't make sense to assess the learning curve of a language when you're also intermixing learning to code...

It's like saying a plane is "harder to learn to fly than other planes" just because a beginner can't learn to fly it quickly.

agumonkey7 tahun yang lalu

learning cliff I'd say

gpm7 tahun yang lalu

Hence why I clarified the point on the learning curve that I, and I expect the author of that line, is interested in.

atoav7 tahun yang lalu

I think it is quite easy to do simple things like opening and closing files reading writing. String manipulation and working with vectors can be similar to python at times..

The ownership concept is a bit harder to grasp, it took me maybe a day to get the initial understanding and a year to really feel comfortable in all situations.

The thing is, now that I understand it it is not only very powerful, but it allows you to think about your code differently: because of the strict ownership rules you tend to be aware at all times of the impact of the code you are looking at in any given moment. Combine this with the strong type system and you really feel in control.

When I moved from python to Rust I probably wouldn’t recommend Rust to beginners. In hindsight I am not so sure about that anymore. It is hard, but it is teaching some concepts every programmer in any language could use and it is incredibly consistent.You rarely find any weird edge cases that are the way the are because of some arbitrary decision. Most language design decisions have been extremely careful considered and you can feel that. This is contrary to many traditional beginner languages, whkch are often filled to the brim with weird edge cases.

The cargo environment is incredible.I wish I had something like this for python

gpm7 tahun yang lalu

> [teaching rust to beginners]

I feel similarly, I'm not sure it would be success, but I think it would have a good chance.

I'm very tempted to try and design a "learn programming via rust" course and then find some guinea pigs (err ... students) to see how it works. If I had infinite free time I definitely would.

atoav7 tahun yang lalu

I learned programming mostly with processing (https://processing.org/) For beginners the huge benefits would be: - instant visual feedback: Loops make much more sense when you can see them - easy to get running (I’d argue rust is the same) - Limited enough to learn basic concepts and not get overwelmed

The hardes thing about teaching any traditional language is probably explaining why it is mostly a command line/terminal thing without huge efforts.

Pristina7 tahun yang lalu

driving a 747 isn't that hard, just turn on the engine and pull up once you are at take off speed.

timw4mail7 tahun yang lalu

Right, the hard part is landing.

justinpombrio7 tahun yang lalu

It's very smooth after you climb the initial brick wall :-).

EDIT: Let me say something of substance. There's a steep learning curve for getting past Rust's borrow checker. But the language documentation and compiler error messages are the best I've seen of any language. I wouldn't say that Rust is an easy language to pick up, but it's surprisingly easy to learn for what it does.

wwright7 tahun yang lalu

Much better than C++’s “climbing the stairs to Moria”

[deleted]7 tahun yang lalu

opan7 tahun yang lalu

It might be an effort to use the more correct meaning, in that a steep learning curve means learning ramps up very fast.

geofft7 tahun yang lalu

"A minute to learn... a lifetime to master."

purplezooey7 tahun yang lalu

Anybody else remember when it was Eight Megs and Constantly Swapping... good times..

komali27 tahun yang lalu

I'm playing around with emacs, slowly trying to get it to feature parity with vscode to see if I could one day use it as a main editor. One thing I'm constantly surprised by is how slow random stuff is in emacs. Maybe my setup is fucked? But simple stuff like holding my "scroll down one line" macro is not smooth at all, the time it takes to get from launch to accepting commands is way higher than vscode, scrolling with the mousewheel is gross, and worst of all, there's input delay on text input. Maybe it's the chrome effect - vscode seems faster because it's hogging my ram? I wish I had checked the memory usage before posting this.

It's a shame because I like the idea of emacs, but I simply can't seem to get it anywhere near as good as vscode.

rkangel7 tahun yang lalu

I came the other way very recently (emacs to VSCode). It wasn't performance that was the issue, it was the level of effort required to get the same level of experience between VSCode and Emacs.

I have used Emacs for about 10 years, and have days upon days of effort invested in my emacs config. Despite this, it took 5 minutes of setup to get a significantly superior setup for the languages I'm using currently (Elixir, Rust, ReasonML, Python). I had more features available (e.g. better highlighting and listing of current errors), and the core ones like auto-complete and go-to-definition worked much more reliably. It took an hour of tweaking some keybindings and settings to remove some UI cruft and navigate between splits and I have something that performs at least as well as Emacs in every regard. It's only been a couple of weeks, but it's promising so far.

komali27 tahun yang lalu

Nice to hear you've managed to get stuff you liked in emacs working in vscode, that's something I'm constantly tweaking as well. Mind sharing your vscode keybindings/settings.json?

ryanolsonx7 tahun yang lalu

Yes, please.

taude7 tahun yang lalu

This doesn't seem right. I'm running it on a five year old computer and it feels way snappier than VSCode. I run on both Windows and OS X and don't have performance issues.

It could be some a rogue package or something with a wonky config?

Also, you should start it with emacsclient (I alias it to a shortcut). Run the emacs server/daemon in the background, and everytime you type your alias with a file name, it'll open almost instantly.

See more on the EmacsWiki page [1]

[1] https://www.emacswiki.org/emacs/EmacsClient

komali27 tahun yang lalu

I went through some stack overflow again and a lot of people are suggesting it could be linum-mode? I have it on everywhere cause I like being able to jump to a line number. But I have emacs 26 which is supposed to have fast, C written linum mode.

TeMPOraL7 tahun yang lalu

The modern, Emacs 26+ mode is: display-line-numbers-mode. This (put in config) will enable it for you globally:

(global-display-line-numbers-mode 1)

linum mode (and the faster contrib, nlinum mode) were used prior to Emacs 26, and sometimes had some performance issues in large files.

Also, all of those are for displaying line numbers on the left margin. Jumping to a particular line in code works always.

(And if you want to go totally oldschool, use column-number-mode and line-number-mode to see the column and line numbers of your current position displayed in the modeline. Or (shameless plug) install nyan-mode ;).)

0db532a07 tahun yang lalu

You don’t need linum-mode to jump to a line number. Just use M-g g, or M-g M-g.

craigsmansion7 tahun yang lalu

To elaborate a little:

"M-x goto-line which is bound to M-g g, or M-g M-g."

Naming the function "goto-line" in full can make it easier to remember for a reader, providing a fallback for when the key-chord isn't part of muscle-memory yet, and provides an easy way to look up the binding in emacs itself:

C-h f <ctrl-h(elp)-f(unction)>

"Describe function:" goto-line

"[..] It is bound to M-g g, M-g M-g [..]"

0db532a07 tahun yang lalu

`C-h k M-g g` (k for key) will also describe what the key-chord `M-g g` is bound to. Also, `C-h k` is bound to the function `describe-key`.

komali27 tahun yang lalu

But how would I know the line number of what I wanna jump to without display line number on? I.e I'm on line 100, want to pop down to a function on 202 (a line I haven't visited yet).

0db532a07 tahun yang lalu

Along with interactive search (C-s forwards, C-r backwards), you can jump to the definition of a symbol (including a function) with ‘M-.’. These would be the idiomatic ways of moving around. There are multiple ways of maintaining up-to-date symbols depending on your context, which you can look up in the documentation for ‘M-.’.

zeveb7 tahun yang lalu

It'd probably be more common to jump, e.g. using ace-jump or plain old interactive search.

pmontra7 tahun yang lalu

Some macros can be very slow but something simple should never be noticeably slower than in any other editor. But what does a macro do to scroll a single line?

About smoothness, maybe, but I don't have any editor to compare it with now, except vim. I remember that NetBeans, Eclipse and some JetBrains editor where not any different on my hardware last time I had to use them.

Startup time, it's a non issue for me because I start it up after boot and keep it running. I load files into it with emacsclient [1] and save the desktop to a file to pick up from where I was after a boot. Surely, with hundreds of buffers it takes a little to finish loading but I don't reboot every month.

[1] https://www.emacswiki.org/emacs/EmacsClient

saghm7 tahun yang lalu

> One thing I'm constantly surprised by is how slow random stuff is in emacs. Maybe my setup is fucked? But simple stuff like holding my "scroll down one line" macro is not smooth at all

That's super interesting, because the main reason I don't use VSCode at all is that whenever I hold down a key, it seems like the key events happen faster than the editor can handle, and it ends up continuing moving well after I've stopped pressing it (which is most annoying when it's the delete key).

jeofken7 tahun yang lalu

In my experience this comes from fancy plugins that do work. ELisp sadly lacks parallelism. Emacs was for me an acquired taste

mrob7 tahun yang lalu

I put some serious effort into trying to use Emacs a few years ago and had the same experience. It's not so bad in the default configuration, but by the time you've installed enough LISP code to reach feature parity with modern editors it slows down annoyingly. Eclipse is noticeably faster.

mgalgs7 tahun yang lalu

> Eclipse is noticeably faster.

You definitely had something misconfigured then...

Not saying that's your problem, emacs could do a lot more to be friendlier to newcomers. I'm just saying, don't be so quick to judge it until you've gotten with your local emacs nerd to see what's wrong with your setup.

komali27 tahun yang lalu

Are you an emacs nerd willing to peek? Maybe it's just spacemacs by definition is fucky, but my machine is a beast so I feel like other people would be complaining about slow spacemacs if that were the case and I can't find much of that out there.

init.el and .spacemacs: https://github.com/komali2/Configs/tree/master/emacs

throwaway4277 tahun yang lalu

Yeah it's spacemacs. Any soup to nuts emacs distribution like this is going to be slow. I experience it all the time in doom. You don't have anything misconfigured.

Features like helm, ivy, projectile, etc cost. Linters and autocomplete can really make emacs jank. All this stuff is configured out the gate in these distributions.

zeveb7 tahun yang lalu

I've found that prelude, at least, isn't too bad, as long as it's not running on my phone.

I really like spacemacs (I'd love to get back to using vi keybindings in emacs), but man is it slow. Awfully cool, though.

mgalgs7 tahun yang lalu

I just took your config for a spin and it's actually quite snappy for me... What exactly is slow for you?

throwaway4277 tahun yang lalu

Are you using a prelude like Prelude, Doom or Spacemacs?

agumonkey7 tahun yang lalu

scrolling and mouse is probably not important in that culture; that said .. text input delay is super sad

pmiller27 tahun yang lalu

Nice operating system, but it really needs a good editor, amirite? ;)

In all seriousness, see https://news.ycombinator.com/item?id=14826070 and http://wiki.c2.com/?EmacsAsOperatingSystem

TeMPOraL7 tahun yang lalu

> Nice operating system, but it really needs a good editor, amirite? ;)

You're rite :). True Emacs enlightenment comes when you realize that this is not a joke - that Emacs really is a kind of OS, and that it offers a much better experience than traditional OSes for any task that's mostly about text (whether linear or 2D). Which is quite a lot of tasks, actually.

m4637 tahun yang lalu

maybe that should be: Exa Megs And Constantly Swapping

or Escape Meta Alt Control Shift

[deleted]7 tahun yang lalu

josteink7 tahun yang lalu

AFAIK GNU Emacs is written using a completely 100% FOSS GPLed stack, preferring GNU components over others when alternatives exist.

So how does Rust play into this? Is the Rust-stack “compatible”?

For this to succeed long term they will have to get their changes mainlined, and it would be a shame if anything as petty as licensing or political over GNU/non-GNU should stop it.

Athas7 tahun yang lalu

I don't think this is the objective. It would certainly never happen - for political reasons, there is no way Emacs would ever depend on a non-GNU compiler.

omeid27 tahun yang lalu

> as petty as licensing or political over GNU/non-GNU should stop it

For any substantial project, licensing is a matter of make it or break, for philosophical and economic reasons. If you think one's philosophy of life or economic approach is pity, you're out of your damn mind.

lprd7 tahun yang lalu

I'm a vim user but I would really love to take a peek into the emacs realm (also interested in Rust development). Is this a good project to start with? Also, I use vim-plug to manage my plugins, is there an equivalent in the emacs world?

Any tips or recommendations are welcome :)

rgoulter7 tahun yang lalu

> Is this a good project to start with?

Probably not. You'd be better off looking at an Emacs distribution to see what's available.

Sacha Chua's Visual Guide to Emacs is excellent. http://sachachua.com/blog/series/a-visual-guide-to-emacs/

There's also an awesome list for it. https://github.com/emacs-tw/awesome-emacs

I'd suggest looking at Magit or Org-Mode. These are often cited as "killer features"/"gateway drugs" for Emacs.

> ... what's the equivalent of vim-plug ...

I liked the discussion on straight.el's readme: https://github.com/raxod502/straight.el/blob/develop/README....

lprd7 tahun yang lalu

Thanks for the recommendations :)

zaiste7 tahun yang lalu

There is also Doom Emacs [1] which provides Vim experience out-of-the-box. It also comes with a fantastic theme.

I've been using Vi/Vim for more than two decades now. Doom made me feel at home. I used to envy Emacs all these nice features such as Org Mode, Magit and even the ability to use Lisp to configure your environment. Now it's the best of both worlds.

I just wish Emacs' onboarding process / cohesiveness was as good as in VS Code. It would be a dream come true. ;)

PS. I've recorded a short Doom screencast for newcomers [2]

[1]: https://github.com/hlissner/doom-emacs [2]: https://www.youtube.com/watch?v=rCMh7srOqvw

lprd7 tahun yang lalu

This looks really interesting. How does it compare to something like spacemacs? I'm confused by all the different "flavors" of emacs. I think I would prefer something like doom to spacemacs since, from the looks of it, you stay inside the terminal. If I want a gui, I'll just use VS Code.

Thank you for the recommendations!

midgetjones7 tahun yang lalu

http://spacemacs.org/

euske7 tahun yang lalu

Does it have unexec?

cf. http://emacshorrors.com/posts/unexecute.html

lokedhs7 tahun yang lalu

Emacs has finally gotten rid of unexec. It's replaced by the portable dumper which which essentially serialised the state of the application using its own format.

gpm7 tahun yang lalu

Assuming this issue is up to date - yes, but it's on the todo list to remove:

https://github.com/remacs/remacs/issues/105

geofft7 tahun yang lalu

Wait, what's the reason for preventing a dumped and reloaded emacs from being re-dumped?

tedunangst7 tahun yang lalu

As linked, it's mostly incompatible with ASLR. If you were to undump to a different address, all the pointers break.

geofft7 tahun yang lalu

Why doesn't that affect the initial dump/unexec?

(Or in other words - if the answer is that ASLR is turned off for either initial exec or reexec, why not keep it turned off so that a third exec works?)

tedunangst7 tahun yang lalu

Oh, it does. Sorry, I missed the point about the double dump. No clue about that. I'm happy not knowing.

testcross7 tahun yang lalu

If I remember correctly, the same kind of hack is used by atom to allow fast startup.

NinoScript7 tahun yang lalu

What a nice job they’re doing. I wish them luck

pzone7 tahun yang lalu

Great to see this project still going strong!

chalst7 tahun yang lalu

How does compile time compare for GNU Emacs vs remacs?

xvilka7 tahun yang lalu

Hopefully one day NeoVim will follow their example.