I chose Elixir over Clojure simply because the web development story is better (in my opinion) due to the community rallying around Phoenix. I preferred the Lispiness of Clojure but all you have over there is Fulcro and Luminus, the former is far, far too complicated and niche, while the latter is just curated libraries.
The ruby-like syntax and the VERY open and newbie-friendly community have definitely contributed to this.
I've been to Elixir conferences, and they felt like people were just encouraging each other to build solid software WITH each other. I've not seen this level of camaraderie for other programming language communities.
Elixir devs — and I am super biased here — are a special bunch :)
That's great to hear! I get the same feeling towards the Clojure community as well, some of the friendliest, smartest and most helpful people hanging out at the Clojure watering holes (in comparison to other languages I've worked with). I also am constantly in awe of the output of the Clojure world. There are like 3 or 4 great podcasts going, so many cool projects being worked on, especially for a community which seems to be sadly so small.
Cognitect, the company behind Clojure also has their own podcast but I haven't found it to be that interesting most of the time, at least yet: https://www.cognitect.com/cognicast/index.html
Not specifically Clojure-related but has discussed a few times including wit Rich Hickey (as well as other unrelated great conversations!): CaSe https://www.case-podcast.org/
Completely not at all about Clojure but great software podcasts:
Go Time: Even though I hardly ever write Go, I find their conversations to be really great and having lessons beyond Go. It helps that I am interested in the language though: https://changelog.com/gotime
I’ve listened to some Defn with mixed results. I really liked their interview with Daniel Higginbotham, especially when they argued a bit about what “simple” means.
Even if some of the others have gone quiet, there plenty of backlog to choose interesting episodes from. The Bike Shed also looks right up my alley. They probably should have had some more discussion before choosing that name, though.
Community can definitely play a role though I can't help but think that Phoenix and the proselytizing done by Jose and co are the main factors.
Sure, we have Luminus in the Clojureverse but its just not as easy and straightforward as the Rails-like experience of Phoenix. You don't have Hickey personally responding to comments on HN/Reddit etc.
Hickey is extremely remote from the Clojure community. Most of Cognitect is. Really, only Alex Miller engages on a regular basis. To a lesser extent, Fogus and Ghadi do, too.
I would agree here that the combination of being "closed to collaboration", the slow pace of development lately, and really infrequent communication from the sole owner/leader/BDFL does send a weird vibe and raises some concern regarding what direction the language is going to be going in in the future.
One of the big reasons, in my opinion, for Clojure failing to fulfill its potential as a mainstream language. Clojure had SO much going for it then it just flatlined. Sad indeed and very much down to its stewardship.
Isn’t one of the beauties of lisp is that you don’t need much from the language creator. It should be far more stable than non-lisp languages, and you can implement most ideas with macros outside of the core language.
You can get a pretty long way but there are still things that need to be improved over time. For example Clojure still 7 years after the java 8 release doesn't have great integration with java 8 functional interfaces, which is a pretty big detriment to java interop. I saw this patch which seems to have been submitted by a community member https://clojure.atlassian.net/browse/CLJ-2637 (not sure if the author is a core contributor or what), but even after month no comment from Rich or anyone else on the team to indicate if this is a good idea, if they'd let it in or what.
Maybe not, but I do agree with him, too many people in open source feel entitled to get stuff for free (beer) without contributing, many corporations that leech on open source as well.
For the most part, Clojure is tuned for experienced developers I think. It's kind of an oximoron, but it feels like it was Rich Hickey's goal as well, to not appeal to any of the "easy" and "convenient" and "familiar", but focus entirely in "no bs", "simple" and "very flexible" pieces that never break backwards compatibility, are always open for extension, keep performance in mind, reaches for battle tested hosts when it can, and all that.
There's a big downside to Clojure having the most amount of experienced developers I think in bringing beginners in. You'd think it be the opposite, but beginners are better treated by other passionate smart beginners and people who just got out of being a beginner. As experienced old devs tend to not have the time or patience or not know how to explain things or make it beginner friendly.
Honestly I wouldn't be using Elixir if it wasn't for my co-founder's singing the praises of Phoenix & Liveview. I'd tried it once about a year ago but couldn't see any advantage over Clojure (esp. with re-frame). Sadly he was never going to move to Clojure.
That said, now I've dug in and really used it for solving some problems I am finding it an elegant and enjoyable experience.
I'd happily use either although I think Elixir has a particular fit to web applications.
Elixir seems to be very approachable. But some of the strengths of Clojure are unmatched, such as Java/JS interop, isomorphic code for web development, and generally being a Lisp (which includes macros).
Elixir has macros. People are currently building Nx https://github.com/elixir-nx/nx while not having to change anything in the language. Java/JS interop being unmatched is true, but Elixir has Erlang interop too.
LiveView sorta tackles the isomorphic web development side, and while I agree that Lisp is a better syntax you do have hygienic macros in Elixir as well.
Yes and no. Yeah Erlang has been around for 30 years but "30 year old language" makes it sound like it came out 30 years ago and then stopped. Erlang is still being very actively developed and improved, it's by no means a crusty old language.
Although Microsoft has made it from Microsoft Research into official Visual Studio, it has been mostly an up hill fight to keep it there, while .NET languages group mostly cares about C# and VB, and to certain extent C++/CLI for integration with Windows APIs.
F# when taken into account by management, comes always after those three.
Most of the Visual Studio tooling for C# and VB isn't available to F# projects, you are supposed to do it manually, e.g. GUI designers, EF database to code generation, .NET 5 code generators.
its funny you say that, Ruby ALSO took a lot from Lisp and lisp like langugaes. there's even a built in parser in Ruby that converts the language into S-expressions
require 'ripper'
Ripper.sexp('a && b')
=> [:program, [[:binary, [:vcall, [:@ident, "a", [1, 0]]], :"&&", [:vcall, [:@ident, "b", [1, 5]]]]]]
Ripper.sexp(<<-RB)
if a
b
else
c
end
RB
=> [:program, [[:if, [:vcall, [:@ident, "a", [1, 5]]], [[:vcall, [:@ident, "b", [2, 4]]]], [:else, [[:vcall, [:@ident, "c", [4, 4]]]]]]]]
Moving to another city leads to a few necessary purchases. I help people find the right services and get a commission. That includes things like health insurance, a bank account and an apartment.
It's just good ol' affiliate marketing, except that I don't build the content around monetisation. I built the sort of honest website I wanted to find when I moved here.
Java moved to a six month release cycle and it has breathed new life into the ecosystem as a whole. Its one of the most robust and important languages out there.
Java will likely never truly die because of legacy applications. It's also still firmly set in the market and that is not looking likely to change in the future. Its also the king of microservices with Spring Boot.
Kotlin could well take over the mobile space. Many of the touted benefits of Kotlin are slowly being added to Java itself.
Java itself may decline as a language, but I'm near certain that the JVM will be with humanity forever. Someone will be programming in a JVM language somewhere. Whether it's some future language or Java 532.
I've not found anything in JavaScript that replaces Django in terms of ecosystem and reliability. There's lots of attempts but Django and Rest Framework nail building out APIs.
Java executes faster than Node but is more verbose.
Choose the right tool for the job. I've put Node as a reverse proxy in front of Django, but now you can do JS in Nginx so I might not choose that pattern again.
Not that I want to pile on, but I didn't make it past 100 pages. It's badly written, and I don't want to waste my time when I could be reading something else.
My visual acuity varies, so I benefit a lot from software that lets me change the size of the elements on the screen. The typical Mac app allows the user to change the size of the text in the main pane, but everything else is a fixed size. In contrast, all the Electron apps I've tested give the user an easy way to change the size of everything, e.g., all the icons in all the panes.
If I had found a way to change the size of everything on one of the Lua-based editors on the Mac, I probably would've switched years ago to one them. (I don't recall their names.)
If I stay with Emacs it will be because learning how to modify vscode, e.g., by writing my own extension, proved too difficult. (I want my editor to be a general interface to information that is easy for me to modify by writing code.)
You can change size of elements in Emacs too. Hint: 99% of what you're looking at is text, so it boils down to changing font sizes. Emacs already has commands for zooming content in a frame, which work like +/-/0 in a web browser.
Thanks for clarifying something I failed to explain. The relative ease with which I can change the size of most of the elements in Emacs is the reason I didn't switch to, for example, Textmate or to Sublime Text when those editors appeared on my radar.
Emacs, terminal emulators, Plan 9 port, Chrome and apps based on Electron are the only apps on the Mac I have been able to figure out how to change the size of most of the elements of.
"most of": The size of the menu-bar and pop-up menus is fixed in all of those apps when they are running on a Mac, but Apple made the text in them large and legible enough to suit me.
Setting the scaling to a fractional value in System Preferences doesn't count because the result is too blurry. I never obtained a monitor with a horizontal resolution of at least 2560, which is the minimum needed to set the scaling to 2 in System Preferences.
I’ve seen this pop up a lot lately—someone who’s been using Emacs or Vim for years and then sees the “new cool” editor and says they’ll be switching to it.
I have the same question, since someone who’s used Emacs for that long would surely have “seen the light” already. Maybe they’re yak shaving with the config instead of getting work done? That’s one of the few valid complaints I can think of.
I used Emacs for a couple of decades but switched over to VS Code after a couple of days of playing with it. I love Emacs and the concept of infinite configurability. But as it turns out, I don't actually use most of that flexibility. It's more common that I'll install a package, tweak a couple of knobs, and get on with work.
Well, VS Code offers the equivalents of all the Emacs packages that I actually use, and they come with sane defaults. Once I've tweaked the Python module a little bit, I tend to ignore its other options and get back to editing code. And in that code editing environment, I honestly prefer VS Code. The key bindings feel like other modern apps (yay for using the same Mac shortcuts for moving around that every thing else uses). Menus (and their shortcuts) work as expected. I don't have Emacs's beautiful macros, but I do have multi-cursor editing which is beautiful in a different way. It's fast. It looks pretty, with nice easier-to-install themes and icon packages. Basically, VS Code does everything that I ask of Emacs, but in a modern package.
I still love Emacs. I had switched to Sublime Text at one point but came back to the 'Macs because ST wasn't good enough to win me over permanently. And I definitely still love the idea that I can rewrite all of Emacs to make it my own personal slice of editing heaven that is optimized for me and me alone. That's wonderful! But now that there's an excellent, MIT-licensed, well supported alternative that doesn't everything that I want in practice, I'm sold.
But if MS ever loses the plot and ruins VS Code, I'll be back on Emacs in a heartbeat.
VS Code does not come with magit... and that in and of itself is a great reason to use Emacs. (This is coming from a daily Vim user) There really is nothing like Magit even as a plugin for VSC. VSC's scm mode is what I'd consider "barely passible". You can do stuff with it, but it's tiny/ugly/not very friendly. And that GitLens plugin doesn't really help with staging files/hunks etc... it's more meta info about past commits.
That said, I've realized that I don't do that much SCM stuff inside my editor. It's nice to have a beautiful client, but I'm comfortable with the git commandline itself and found myself using it for the tricky stuff, even when I had Magit at my fingertips.
My main editor-integrated workflow involves switching branches, committing, pulling, and other routing stuff that VSC handles just fine. It's definitely no Magit, but it covers 95% of the stuff I do.
I used VSCode for a few years, but never found a way to work with code in semantic units vs. as text. And I like that no matter what language I'm working in, the experience is the same. VSCode plugin editors may or may not (read: wouldn't have) agreed on a set of conventions for working with code independent of the programming language.
I tried that, but it never worked as well for me as it did in Sublime Text, or more recently VS Code.
I get what you mean about Emacs's nearly universal code conventions, but that's an example of something I personally found to be more useful in theory than in practice. While I love the concept, 95% of the time I'm hacking around in Python. The rest of the time is a hodge-podge of shell scripts and the rare C snippet. Maybe a little SQL now and then, or perhaps some JavaScript. When I'm working in something that isn't my usual, I find myself spending much more time reading code than writing it, and in that context I don't get as much benefit from those conventions.
Of course this is all incredibly subjective. If you get a lot of benefit from that, awesome! I can definitely see the appeal. I just don't feel like it makes a whole lot of difference for me.
I admit that I have spent a lot of time adjusting Emacs to my preferences (by writing Emacs Lisp code that gets loaded automatically every time my Emacs starts). I am not particularly unhappy about that fact however and will probably spend a lot of time writing code that runs inside vscode if it becomes my daily driver.
Note that I use the graphical interface to Emacs and would've left Emacs many years ago if itworked only inside the terminal environment. I'm guessing you prefer to work in the terminal environment.
Many people don't realize it, but Emacs has been able to act somewhat like a native GTK+ app, a native Mac app or an native Windows app since the early 1990s. "somewhat": right clicking does something idiosyncratic (namely, if there is already an selection, the click causes the start or the end of the selection to move to the site of the click, which is behavior I've not seen in any other GUI; the standard behavior of course being to pop up a contextual menu, which by the way is what I adjusted my Emacs to do by writing about 100 lines of Emacs Lisp code) but left clicking moves the insertion point to the site of the click (the conventional behavior on Mac and Windows) and dragging the mouse does the conventional thing, too.
I like the "just the fact" nature of the terminal environment, but I also like pointing devices. Emacs and vscode (and Plan 9, but Plan 9 has problems that prevented me from ever spending much time there) constitute a happy middle ground between the terminal environment and the overly chaotic environments of Mac apps in general, Windows apps in general and the web. I have yet to see vscode's being used intensively (like Emacs is being used) for tasks other than programming, but would be delighted if vscode or maybe some platform derived from vscode were to start being used like that.
Maybe I will be the first one to write a really popular vscode extension designed for some purpose other than programming.
> f there is already an selection, the click causes the start or the end of the selection to move to the site of the click, which is behavior I've not seen in any other GUI
Emacs does that in X11 because that is (or at least was) the standard behavior for text selection in X11. Emacs is simply conforming to the environment it is running within.
Emacs's Mac (graphical) interface does that, too, which is not conforming to the environment it is running in.
And there is no user option for changing it to a contextual menu containing Cut, Copy, Paste, etc. (I changed it for myself by writing about 100 lines of Emacs Lisp.)
Emacs was taught to run graphically with X11 first, and presumably operates that way across platforms for a consistent interface irrespective of platform.
Even iTerm supports middle-click paste. Unix people are used to it.
I would guess that’s because IIRC, there’s no official support for Emacs to display native windows in Cocoa, and Emacs is simply using macOS’ X11 compatibility system.
If you could fix that behavior so that Emacs behaves more like a native Cocoa application, I see no reason that the Emacs maintainers should reject a patch. Emacs has, as far as I can tell, always strived to use as much of a native system’s interface and conventions as possible. Emacs is very big, so it might seem to be a self-contained world of its own, but it’s trying not to be too idiosyncratic.
>I would guess that’s because IIRC, there’s no official support for Emacs to display native windows in Cocoa
You would guess wrong.
(If you install an X server, you can run Emacs on X11 on a Mac, but if you do, the text looks radically different from the text in other Mac apps. ADDED. whereas if you run Emacs directly on Cocoa, the way most Emacs users on Mac do it excepting the ones running Emacs inside a terminal environment, the text looks exactly the same as the text in, e.g., Textmate or Terminal.app.)
Hmm. I would then assume that Emacs has rudimentary rendering support in Cocoa, but is otherwise treating it as a variant of X11, and not the fully different graphical system it presumably is. Emacs still has no full-fledged Cocoa integration. That is still only available in the Aquamacs fork, as far as I know: http://aquamacs.org/
This is true. I hope I did not give a contrary impression? I was, somewhat briefly, aware of some of the complexities of Emacs running under NeXTSTEP (not the text-only Emacs 18 included with NeXTSTEP, but proper Emacs 19 with NeXTSTEP windowing support), but that was (obviously) many years ago, and I don’t claim to remember any of it. And I was certainly not involved in implementing any of it.
It's on a different computer than the one I am using now, so it is going to take me at least a few hours to share it. I will make another reply to your comment when I have it.
Ultimately, VS Code just works. I have bounced between Emacs and VS Code as a long time (many years) Emacs user. Things break less often, the extensions are nice, the extension model of the editor is much more coherent, and JavaScript is just a language I find easier to work with. It is much easier to find JavaScript that already solves some problem I have if I am extending the editor. The Python support is good enough. The extensions are all fine. The integrated terminal is actually quite decent, whereas Emacs integrated terminals have never actually been very good in my opinion. Lots of little things. I still use emacs for some things, but generally... VS Code is also open source so I am not too worried about the longevity of the editor at this point. Those are some things off the top of my head.
Oddly I left vscode for emacs for Tramp. Tramp makes it possible for me to have autocomplete, remote repl, remote debugging out of the box (with the python layer plugins in spacemacs). sshfs + terminal never felt integrated and autocomplete doesn't work from the python environment in the remote machine. That was the moment I thought that the flexibility of emacs is hard to match with text editors having a plugin system. I wonder if something like tramp will ever be written into vscode.
I use emacs `-nw` within tmux, on iterm2/3 on mac. There are several terrible problems with this setup which I've never bothered to lose a weekend to trying to sort out (don't misunderstand me: I have lost weekends to some of these problems, and I'm running out of spare weekends).
mac pbcopy/paste into emacs does strange and horrible things. Mouse and scroll-wheel integration roughly doesn't work at all. The list is long.
I also use terminal tools a lot (data engineering), so the terminal itself (and hence tmux) is an important part of my toolset. Meaning, I can't abandon the terminal. Nor do I want to -- as others have said, I have RSI issues with touchpads and mouse-clicking. Spectacle on Mac (or any actual tiling window manager on linux desktops) helps with that, but if I never had to touch a mouse/trackball again in my life, that would be awesome.
As others have said, I mostly want to use an integrated editor and get on with my job, rather than go down a half-century old rabbit hole of reading SICP just to tweak some editor defaults. Again, don't misunderstand me: learning LISP changed my life, man. But that's not the same as "can I enable rainbow delimiters for protobuf" (As an aside, Little Schemer is a much gentler intro to LISP, and also awesome.)
And since I know we're a community of people who get distracted by the next shiny problem to solve: please don't focus on trying to fix the list of issues I'm describing. That's not the point (and I have no spare weekends).
>Mouse and scroll-wheel integration roughly doesn't work at all.
emacs, when started with the -nw flag, has nothing to do with mouse gestures. The terminal emulator (iterm in your case) sits between you and emacs and does not pass mouse gestures to emacs.
Actually, to be painfully precise, there is a convention, which iterm and emacs might or might not use, by which iterm could conceivably pass the location of single left clicks to the emacs process, but, e.g., mouse drag events and scroll-wheel events never get passed.
So for example when the users drags the mouse, then presses Command-C, `emacs -nw` has no way of knowing the user did that, and if anything got into the system clipboard, that is iterm's doing, not emacs's.
Might I suggest `open Emacs.app` rather than `emacs -nw`?
Except for a GNU or Emacs logo that can be suppressed by setting the variable inhibit-startup-screen to non-nil and except for a tool bar that can be suppressed by evalling `(tool-bar-mode -1)`, the result is indistinguishable from a terminal window to most Mac users, but has mouse and scroll-wheel integration.
To be precise, after `(server-start)` is evalled inside the Emacs.app process, whenever the command line `emacsclient <file name>` runs anywhere, inside or outside the Emacs.app process, the Emacs.app "visits" (opens) <file name>.
I am one of those people who talked about switching from emacs to VS Code. I ended up learning just enough to teach it to my daughter, then stuck with emacs for everything I do myself.
Now that I read about all these younger people switching to emacs I feel even less inclined to "modernize" even though VS Code does look like a nice programmable editor.
