Atom is so slow it's a sideshow. It also has the problem of jEdit and Komodo, not a native app so they greatly reduce battery life on laptops.
Just because Sublime's developer isn't updating it as much as he used to doesn't mean anything. What more could you want? The community hasn't stopped with plugin development which is what really counts.
This just reminds me of the consumer software mindset where a new version needs to come out every year, just for the sake of it. There's nothing wrong with using 'old' software that just works.
> Atom is so slow it's a sideshow. It also has the problem of jEdit and Komodo, not a native app so they greatly reduce battery life on laptops.
Granted I would expected it to be slower using an interpreted language and all but other than opening large files the only thing noticeably slower to me is start-up. That's it. The plug-in ecosystem got me to permanently switch to Atom and it's very fast. I also haven't noticed any battery issues yet as I still will frequently use my MacBook for sometimes most of a day before needing to charge.
I'm not sure if you were speaking from experience with Atom or just approximating but it's surprisingly good. I know I was extremely skeptical to the point of calling it a dumb idea to write an editor in the way they did but after they dumped react I don't notice any slowdowns.
I agree with you. The slower start compared to ST is not a problem for me and a lot of the other things atom provides for me are good enough positives for me to have switched to it and not looked back.
Can I ask what you mean with large files? I haven't tried Atom in a while but I recall it having issues with something as small as 2MB.
Granted, I typically use Sublime in a way that others probably do not...more for manipulating / viewing data than actual coding. Outside of HTML, JS & CSS, I tend to use IDEs for development (VS for C#, XCode for ObjC and Jetbrains for most everything else). Maybe Atom isn't meant for that type of use and it much more suited for use as something akin to an IDE.
All that being said, I have found nothing that compares to Sublime for simple data viewing / manipulation (regex)...it seems to have no issues with 100+ MB files where as I don't even know if Atom could open something that large.
> Can I ask what you mean with large files? I haven't tried Atom in a while but I recall it having issues with something as small as 2MB.
Since I only use Atom to write code I would consider anything over, say, 200kb a large file. Unless it's a log file I never open anything larger than that in Atom. A few MB usually isn't too bad but once I hit around 5MB it gets to be just too slow.
My usual goto for simple data viewing / manipulation (regex) is geany. I find it's search and replace to be a little friendly for me. Though I do miss some dialog keybinds that I can't seem to find anymore on Mac OSX (the ones for document only vs selection only vs entire session for substitutions).
>the only thing noticeably slower to me is start-up
That's a big pain point, if you switch between windows (e.g. browsers - including some tabs/incognito for testing etc.). After having used eclipse when I moved to ST 3/4 years ago. I realized what I was missing. Faster start time and switching is a must. I normally have 3/4 projects (i.e ST sessions open). And just using key board (ctrl-tab) switch between them, and its almost instantaneous.
I typically use it for coding Go, bit of C++ and web UI (javascript etc).
The fast feel is so good, that now, I think even if I need to start a Java project, I will try ST with some appropriate plugins.
I'm not sure I follow. Start-up time and switching time are two completely different things. In web browsers sure switching between tabs can slow down because they deallocate between them after some time but Atom doesn't do that. Switching is always instant in Atom because it's all kept in memory.
I typically have 4-5 Atom windows open all with multiple files open and each has always opened instantly when switching.
I do understand the difference between start-up time and switching time. I included the latter to tell about my experience with editors like eclipse (and other editors developed in Java).
Have not used Atom. Great for you, if you like it.
My point being, when I started to use ST (which has been coded in C++). It dawned on me, that most editors not coded in C/C++ (or coded in Java, which are the ones I used) are slow, mainly because of lots of extra memory usage. Using ST also brought back the memories of fast and responsive Vi(m) earlier. I recalled, even MS Visual C++ (which I believe is done in either C or C++), which I used before eclipse/etc was quite fast. Hence my submission. So now, I don't think I am going to like using a coding editor, which is done in any garbage collected language (basically any non C/C++ language). As a side note, when I tried to use the DartEditor for coding in Dart, after having tasted ST, I was thinking why did Dart team not make a simple ST plugin instead? I believe an editor could make a difference in adoption of a new language. In love with ST.
> Javascript isn't interpreted, it is dynamically typed, but there is a compilation process before any JS code even executes.
Being interpreted and dynamically typed are not mutually exclusive. Regardless I'm not going to get into a pedantic argument about what is or isn't an interpreted language because it's ridiculous. If you feel strongly about JavaScript not being an interpreted language, as per your personal definition of interpreted languages, then feel free to update the wikipedia article (https://en.wikipedia.org/wiki/Interpreted_language).
> The plugin system is great. But updating, searching, parsing, is very slow.
I haven't noticed. By the time I get to the point of needing a search function over a project (because in file is instant) it's not the fastest operation in any editor.
> Have you tried displaying the keybindings? It takes forever.
Yeah though I've never noticed any slow down in doing so (seems to open in less than a second every time I try it on my MacBook Air). Regardless keybindings is something I'd open once every 3 months-ish; so it could take 20 minutes to open for all I care as long as the editor itself is fast and improves my productivity, which at the moment it does (I previously used Sublime).
I move to whatever editor makes me more productive. I have no loyalty here. I tried Visual Studio Code which was pretty nice but I'm too used to tabs and had to move back to Atom.
Try putting a few base64 encoded images in a file and move your cursor. It doesn't work. Keep atom open for a week without turning your computer off. It crashes randomly. There are countless problems with slowness and lag that I have encountered when I leave the app in the background / foreground for a very long period (days to weeks). After trying to use atom for at least 6 months, I'm back to sublime.
You're opening files with base64 encoded images in them? That sounds like hell either way :D
Yeah I've opened maybe one or two files like that before. I honestly can't remember if there was an issue or not but like I said I would be shocked if I ever needed to open a file that's bigger than, say, 200kb in Atom. If I need to open a big file that's, say, logs or contains base64 encoded stuff in it then I use Sublime. Atom just isn't a good fit for opening large files.
I dont get why people only discuss Atom vs Sublime. Is programming world in such a need for A vs B discussions again? There are probably at least 5 text editors for coding worth checking out.
There is Brackets as well, which I am using with no problem since 6 months. The core program has not failed to do its job even once during this time. No crashes, stellar performance.
So if you annoyed by Atom and not sure about Sublime and its cost - try Brackets. I bet you you will love it.
Perhaps it's because Atom sort of bills itself as a hackable, JS/HTML version of Sublime. It's a very apples-to-apples comparison, while Brackets targets a particular niche and isn't as directly comparable.
You might not realize you want something until you have it.
Switching to Atom a few months ago let me get things linting errors displayed inline [1]. Sublime plugins have very limited ability to tweak the editor contents.
There's also a neat Git plugin that turns Git's textual conflict markers into live markers allowing you pick which side to use. It also displays a list of pending project-wide conflicts while you're working — also not something Sublime plugins can do.
The Markdown Preview package is very nice. It displays a preview window inside Atom. Sublime can't do this because of the API.
Atom has a bunch of Go packages that autoformat on save, provide "intelligent" autocompletion (e.g. type a variable and a dot and it will suggest methods callable on the variable), lint/syntax check, and so on. (In particular, Atom's autocompletion mechanism is extensible; plugins can provide completions based on context. Sublime's autocompleter is hardwired, I believe.) There are some Go packages for Sublime, but they never worked properly for me. The ones for Atom are quite polished and just work.
Sublime plugins can't modify the file sidebar. With Atom, I can have the sidebar colorized based on Git status, for example.
The color-picker package is great — when editing CSS you can get a little color picker popup for color codes. Again, not possible in Sublime.
In short: Sublime has a very limited plugin API that supports very little side from editing text. Atom's API opens up a ton of possibilities that simply can't be done in Sublime.
When I was doing DoD work being able to print code was amazingly important since it's not always easy to bring computers / files into certain environments but paper? Yeah pretty important even to this day in that area. Now that I stopped doing DoD work I literally have zero use for it.
Note, I own Sublime and still use it. However, I do see great value in the Atom project. Developers shouldn't fall in love with an editor. Key bindings perhaps. The ideal editor would let me turn it into vim or Emacs, for example.
>Then you apply an exponential curve and one day the much larger development community and Moore's Law push Atom past Sublime.
First, there are no more free "Moore's Law pushes". There haven't been any to write home about for at least 2-3 years. It's now all about multicore (which is also not exactly the best thing for a JS based editor to benefit from).
Another issue is that JS performance has already reached most of the optimizations out there. With the JIT-based JS engines there has been a 100x or more speedup from early JS to circa 2010 or so. Not it's at best some 20%-30% speedup year over year, and that only in some narrow cases. Even webassemply (when that lands as a viable option) is not expected to change that much.
As for the larger developer community, ST already has a huge development community for plugins -- which is where most of the action happens. And sometimes a talented programmer with a strong opinion can be better than "design by comitee".
That said, I find Atom to be a nicely designed editor which would have a great potential, if only it wasn't burdened with a crappy architecture and runtime choices. It might not even be JS fault, as Microsofts VS Code seems to do much better.
Moore's Law isn't over. You are asking us to believe the recent past means that we will not get more single cpu performance increases over the next 10-20 years.
And you're saying that a 20%-30% (6x-13x) improvement over then next 10 years won't make a big difference? If Atom was 10x faster, would it be more useable?
As for concurrency not being applicable, that might be true for some tasks but I can easily imagine scenarios where is would help greatly. Multiple buffers and files. Replace and search for example. Indexing, concurrent garbage collectors, ...
So, in your scenario, if cpu's only become 10x faster and we get 60 CPUs, we won't be able to make a better editor?
The "transistor count" version of Moore's Law has been saved by multiple cores. The speed version hasn't been true for single core performance for years.
> You are asking us to believe the recent past means that we will not get more single cpu performance increases over the next 10-20 years.*
Moore's law is put in specific time terms -- transistors/power(speed) should double every 18 months. So if this hasn't been the case for the recent 2-3 years, then Moore's Law is already broken -- no belief required. The fact that it's very possible we'll might see another CPU speed breakthrough in, say, 2022 or 2028 or 2050 doesn't change that -- as Moore's Law talks about sustained improvements over 18 month periods.
Besides, few in the industry disagree that the Moore Law is pretty much over. That's a great motive behind all the talk of optimizing multicore performance, functional techniques etc.
>And you're saying that a 20%-30% (6x-13x) improvement over then next 10 years won't make a big difference? If Atom was 10x faster, would it be more useable?
As already said, this 20-30% is "at best" and covers specific benchmarks and uses, not general speed. And nobody said this is sustainable long term either. After a JIT engine reaches a specific point of sophistication, there are few things that one can add to make it even faster.
Case in Point: Java. Were it possible to make it as fast as C/C++ for the general case, there's been enough money and time thrown at it to get it there. It's fast (frequently fast enough), but it's absolutely plateaued. That Javascript is nearly on par with Java tells me that it's also nearing its own plateau.
>Next month, the worldwide semiconductor industry will formally acknowledge what has become increasingly obvious to everyone involved: Moore's law, the principle that has powered the information-technology revolution since the 1960s, is nearing its end.
No, I mean an editor that allows you to build a complete vim with macros, for example. The source for vim wouldn't be in C and you could implement plugins like EasyMotion.
Only if you want all the stuff (including crap) that vim offers. If you're OK with the 50-100 core commands, then those emulations can be perfectly fine.
(Also some of us used vi too, and that didn't have all the stuff vim comes with either).
Improvements in single-core performance (the kind that matters for Javascript and most real-world applications) has been near-stagnant for many years now.
Your projection also implies that programmers of the future won't also produce exponentially slower code. I have doubts about that, considering how unresponsive programs these days are, compared to their counterparts of two decades ago (when most programmers actually cared about performance).
Why the heck doesn't he stop calling 3 'beta'? Many people are being led by the naming and web page instructions to install 2, only to find that 3 'beta' is really the one everyone in the know is using, and that plugins are being developed for.
People with ST2 licences can use ST3 while it's in beta but will have to pay for an upgrade to 3 when it is released, so it's perhaps for that reason that he's yet to remove the beta tag.
I believe you'll have great results with Sublime Text 3, why don't you give it a try this weekend? It's extremely stable and I haven't had any issues with it!
I've used the 3dev builds since they were first released and have zero complaints with stability. Sometimes there is a regression introduced, but it's fixed almost immediately.
Dude, you go to the SublimeText web page, and it leads you to download ST2.
There's no way to know 'everyone' is really using ST3 beta except if you learn it from a social network.
Yes, if I go to a website for a product I haven't used before, and there's a big download link for X.0 version, and a link somewhere else on some other page for x+1.0.beta, I'm going to download the X.0 even if I _do_ find that other page.
>There's no way to know 'everyone' is really using ST3 beta except if you learn it from a social network.
A social network, tons of posts and articles on the subject on blogs and web outlets, Hacker News (which has covered the editor several times in the past), plus the official forums.
If it's a tool you use everyday for hours on end (which is what programmers do with their editor), then you can go out and read a few things about that. People spend hours reading on their favorite shows, car models, NFL games, movies etc -- and those are just hobbies, whereas this is a professional tool.
A huge portion of value with any of these text editors come from plugins and ubiquity. Over the years I have seen text editors come and go as the new "one true editor", but only Vim and Emacs have had true staying power.
Back when it was hot (some of you are probably too young to remember this) I used jEdit. It is still around and gets some maintenance updates from time to time (http://www.jedit.org/), but the plugin ecosystem has languished so you better be ready to roll your own.
With Vim and Emacs (Vim for me) I can trust it to go anywhere I want to be. If I'm ssh-ing into a Redhat 5 production server needing to do an emergency fix at 3 in the am Vim is there for me.
And when I need syntax support or any plugin under the sun, that is available as well. Vim is also blazingly fast compared to Atom (the latest fad) which is sluggish by comparison. Sublime seems to be falling into that sunsetting stage the same as jEdit
I'm not sure I understand what your comment has to do with Sublime...but in any case, Sublime does have a very active plugin ecosystem: https://packagecontrol.io/
1) Vim and Emacs are already on your production servers so a large number of people have to use them anyway so that's extra mental overhead.
2) Sublime development is languishing this will eventually lead to a stalled plugin pipeline and the need to learn a new tool or write your own plugins.
3) Stick with a tool that you can have a level of faith will still be well supported for the next 20 years.
How is sublime fundamentally different? Sure, it might be shinier and easier to get into, but is it a different "paradigm"? No way.
If anything, vim is the most unique editor with the most unique "paradigm" I've ever really had much experience with. Atom, Sublime and Emacs all seem pretty much the same in terms of how you interact with them.
Pretty sure saint ignucius will damn you to proprietary software hell for dissing on the One True Editor (tm).
> 1) Vim and Emacs are already on your production servers so a large number of people have to use them anyway so that's extra mental overhead.
Production servers usually have no vim plugins. Basic vim editing is good enough to get by if you're just looking at logs.
In my workplace and I guess it's pretty standard these days (in Linux shops at least) where the code repository resides on a server in a data center and not locally on your laptop/desktop.
Here are the issues with this development work flow:
- There are a lot of hurdles to go through to install all the vim plugins (no root access, security of plugins etc.)
- Which plugin manager to use (Vundle, pathogen or some variant??). Why isn't there a standard for this after all these years?
- Unreadable .vimrc file with all sorts of key bindings (Yes I know it's "write once use everywhere", it still is unreadable a few months down the line)
- In my experience, using vim on a mounted drive with the plugins I need (git,ctrl-p,ctags,cscope,nerd tree and a few others) is slower as compared to Sublime Text.
> 2) Sublime development is languishing this will eventually lead to a stalled plugin pipeline and the need to learn a new tool or write your own plugins.
The Java runtime is not bundled with OSX anymore, and with its poor security record it's not something I'm eager to install. Java GUI apps also tend to use too much resources, feel laggy and look bad & non-native, jEdit is not an exception.
My dream editor is Sublime3 with an extensible UI layer for plugins in HTML/JS.
> The Java runtime is not bundled with OSX anymore, and with its poor security record it's not something I'm eager to install. Java GUI apps also tend to use too much resources, feel laggy and look bad & non-native, jEdit is not an exception.
This is a funny myth.
Now to some facts:
1. It’s the Applet part that has a bad security record. Not standalone Applications.
2. Java GUI apps use less resources, are less laggy, and more native than any node.JS app out there. jEdit is not an exception.
It’s crazy to see people hype Atom for being node-webkit, extensible, etc, but complain about Java apps for "bundles a whole runtime" (while node-webkit bundles a whole browser), for "so slow and laggy" (but faster than node-webkit), for "looks not native" (but more than node-webkit)
I found that intellij was indexing all the time, slowly.
In comparison eclipse never seems to index anything (and it has great type etc. search capabilities).
Intellij really seems like a slow java-app compared with eclipse (which of course is java but using a better toolkit).
I was certainly not advocating anyone should adopt jEdit these days. I was merely comparing it's rise and decline to be similar to what I believe is currently happening with Sublime. I suspect in time we will see the same thing happen with Atom.
Incidentally, I have used Atom and while I found it to be too slow and lacking features, I'm quite pleased it was made since it spawned the Electron project which is pretty awesome.
Electron is cool and all, but every application with it bundles its own entire web browser stack and uses ~200MB+ of RAM (and that's the low end—VS Code with 2 small files open).
Yes Vim is great. This post has nothing to do with Vim, why did you make a comment about how much you love Vim? Is your point that you think Sublime has no staying power so everyone should just use Vim or Emacs?
There's reasons other than staying power to use an application. If I only used applications that I expect to be around forever I'd be paralyzed and unable to make a decision a lot of the time.
I agree that staying power is not the only reason to stick with an application, however I don't believe Sublime offers any compellingly advantages over Vim or Emacs and that there are better ways to spend one's time than learning the current text editor of the year.
So because you prefer Vim/Emacs you came into a thread about the new version of another editor and posted a comment about how much you prefer something else? Do you get why that's immature and pointless?
Notepad++ is my light-weight text editor, for the stuff I don't already have in my Visual Studio solutions. It's free, it's good, it's fast, and you can run it portable if you want to. Windows only, but that's not a problem for me.
Vim and Emacs are great for a certain percentage of people, but for the rest of us mere mortals, Sublime is a great choice.
It's very fast, handles huge files/projects and has plugins and extensions for a wide range of tasks.
The only downside is that the developer retains complete control and updates are few and far between. It would be great if the project could become more open and we could see more focused development on it.
Sublime is a great editor. I purchased Sublime many years ago and improved my ability to work. Now I'm using Atom because I like the way it looks, it does everything I need it to do, and while it may be slow to open, I leave it open anyway so it's not really an issue for me (note: Of course I want everything to be as fast as possible).
That said, I still support Sublime and would still even buy the upgrade to the new version if it ever comes out.
(Disclaimer: I am a _huge_ Sublime fan. I picked up their net award in 2014 on behalf of Sublime HQ Pty, plus I've developed a fair few plugins for it.)
I've been using Atom for a couple of weeks now, mainly for a few Laravel applications. I use the git-hide package to remove the ".git", "node_modules" and "vendor" directories from the tree view which does seem to have a nice effect on speed.
That said, here are the issues I face:
- I frequently find that I type too quickly for the editor to pick up the keys and I end up missing off the beginning of some lines.
- I still use Sublime text daily for quickly opening a file, rather than waiting for a new Atom instance to open.
- PHP support is awful. Auto complete for class names in any used packages is something that I sorely miss from the Sublime plugin I use.
- Start-up time still takes a few seconds which means I only use it for projects.
- Listing of installed and discovery of packages is _so_ slow. Sometimes I just don't bother installing a package anymore because it takes at least 10 seconds to show me what I have installed or search for one.
Regardless of me using Atom, I'm still loving the updates to Sublime and continue to moderate the forums, knowing that Jon will deliver :)
VSCode doesn't have some of the problems you mentioned, notably the startup time. No discernible difference between it and Notepad.
That's not to say that it doesn't have its own problems. One massive pain-point: I was assisting with a getting a complex build system working a few months back. The VSCode build integration is scenario-driven garbage. Because I deviated from the most basic of scenarios I had to resort to all manner of nasty hacks to avoid having contributors open a CLI.
> I use the git-hide package to remove the ".git", "node_modules" and "vendor" directories from the tree view which does seem to have a nice effect on speed.
I feel it'll never be a sensible choice until people no longer have to type sentences like this.
I hope someone's already working on the successor to Atom. A piece of software like text-editor only has a shelf-life of a few short years before you need to start from scratch and write a new one.
>A piece of software like text-editor only has a shelf-life of a few short years before you need to start from scratch and write a new one.
A piece of software like a programming editor, which until now leaves a lot to be desired, even in the most popular implementations (Vim, Emacs, ST, Atom, etc), sure needs constant reinvention and refinement until someone finally gets it right.
Atom would be close to that if it was not fucking based on web technologies. ST3 would be that if it was open source (so the APIs/internals could be improved faster). Emacs would be that if it wasn't based on a 30+ year old UI model and elisp. Vim would be that if it was more extensible and not 100% focused on the CLI experience.
No, it's much better to avoid posting sarcasm at all. It nearly never scans, and it doesn't really fit the HN culture in any case.
Also, your underlying point is practically offensive to the hacker mindset. Though there is nearly a cult-like devotion to the editing tools of yore, the devotion is not universal.
I know /s, and perhaps I'm getting old and idiosyncratic, but I really don't understand why invent new text editors (Sublime, Atom, ...) at this point.
With emacs and vim around, I'd argue that text editors is a solved problem, if there ever was one. It is very hard to match emacs in terms of useful features or adaptability. Granted, the learning curve has a reputation for being steep, and elisp could need a facelift, but I think addressing these problems would provide much more value than reinventing the wheel with another shiny editor.
Intel's top scientists are hard at work developing even slower and more inefficient programming languages and display technologies. I'm confident by the time we have 10 GHz processors, we'll also have a new generation of software that makes it perform like a 66Mhz 486DX.
The only problem I have with Atom and siblings like VSCode is that they are way slower than native software (like Emacs or Sublime). So I'm waiting for editors like 4coder to come to life
Note that Atom and VSCode are "siblings" only in a very loose sense: they use the same app packaging technology [1]. This is enough for your point w.r.t. native software, but VSCode being a fork from Atom is a common misconception.
Then again, emacs is not really native code. Everything outside the basic editing and display layer is implemented in elisp, whose VM and GC are not exactly state of the art (single threaded, no JIT, basic mark/sweep).
It still somehow manages to feel faster than many other editors.
Well Emacs is faster to me because its just a lisp interpreter written in C, tightly close to the hardware. So yes, Emacs is like 80% Elisp, but it still runs fast, and its stable. Editors like Atom are a bit too... "abstract" maybe. If I understand, Atom is CoffeeScript/JS running on a the Electron shell which runs on NodeJS which is written in C++ IIRC. Thats at least 3 levels of abstraction in my point of view, and knowing that Electron is Chrome based, it can't improve its speed. Simpler is faster
What happened to Lime? [1]
It looked promising (especially since it was from the author of SublimeClang [2] which worked like a charm, but now it's dead too and doesn't work with SublimeText 3), but there hasn't been any activity for half a year.
Is there any plugin/editor combination that still does C completion like SublimeClang used to do?
When atom first came out and i tried I said no thank you as it genuinely was painfully slow.
I have been using atom now full time for 3 weeks and gave it another chance as I love a lot of the plugins it has and the community and I am very impressed.
Regarding its slowness it has improved a lot. The only complaint I have with its speed compared to a native app like sublime is that it is slow in starting. This doesn't affect me much as when I am working on a project I leave it open all the time anyway :-)
Give it a try and get some of the useful plugins and you will never look back.
Start-up and creating a new window can still take a good 3 seconds on my machine. Visual Studio (the huge IDE, not VS Code) is actually faster to start most of the time.
Atom is fine for many people's usage of it, and it does some interesting things. It is not without merit. But until issues like this go away, I can't consider it. I regularly need to work with text files several hundred megabytes large. Atom cannot handle this usage. And before you say "Well, you're deliberately being difficult"... I am either taking a quick look at big csv files or automatically generated XML files that store configuration information for some of the systems I work on. A 120 MB XML config file isn't unusual.
Pretty much what it says in my profile. Instrumentation systems. The system topology and configuration for each card, parameter, etc. are all defined in an XML document. With thousands of parameters these files become quite large.
I use Sublime to look and search very big files as well, it seems like basic functionality. Examples would include experimental pressure / temperature measurements, numerical simulation results, large geoJSON datasets...
And does not being actively developed anymore suddenly makes it unusable? I don't think I ran into a bug in years, it's fast and supports everything I need. Moving to Atom sounds like a downgrade to me.
Yeah, I'm baffled by the idea of trading lots of useful features and much better performance just to use a piece of software which is under more active development.
ST3 is a great editor. My biggest problem with the recent pause in development is that I have to install a plugin to get Rust syntax highlighting.
It's good hey! I ran a small POC project using discourse and really enjoyed it, there were a few UX / workflow related things that needed fixing but over all the community really enjoyed using it.
Is that because of all the forum spam? I went to the forum a month or two ago looking for an update on where Sublime was at and it was just overrun with junk posts.
I presume so, at least that would've played a big part in it.
As a moderator of the forum, I try my best to keep on top of it. The old forum didn't have mail notifications or a decent spam blocker, so it was a lot of manual work.
I installed textmate 2 for S and Gs. I have to say it is elegantly impressive. Many not all of the bundles many would need. My only gripe I miss it on Linux. Sublime Text ubiquitous nature is a big attraction in this regard.
Quite a lot of people (myself including) just use v3 regardless.
I honestly think Jon Skinner could just release the next version as 3.0 and few people would mind since most people treat the current beta as an RC anyway.
If ST 2 is any indication, it'll be in beta for a while longer, then 4.0 beta will start (paid upgrade) and 3 will no longer be developed. It's a bit of a silly way to monetize. I haven't actually gotten a license for 3 because of that, I'd rather not pay for beta software or for software that I know will hardly be maintained once out of beta.
I'm pretty sure current license keys work for both 2 and 3. Although it's not doc'd clearly, which does not inspire confidence. But my existing license key for 2 worked for 3 beta, and the FAQ[1] says "A license is valid for Sublime Text 3, and includes all point updates, as well as access to prior versions (e.g., Sublime Text 2). Future major versions, such as Sublime Text 4, will be a paid upgrade."
But if you already have a license key for 2, there's no risk, download 3 and see if it accepts your existing license key -- I think it might.
The way I understand it, is that they are currently (and for quite a while now) not selling Sublime 2 licenses, but only Sublime 3 licenses, which are backward compatible with Sublime 2.
If you have a Sublime 2 license, you will have to pay to upgrade to 3 once it is out.
>I haven't actually gotten a license for 3 because of that, I'd rather not pay for beta software or for software that I know will hardly be maintained once out of beta.
Those names are arbitrary BS.
ST3 hasn't felt like "beta" software for 2+ years.
If he had released it as ST3 2-3 years ago, nothing would have changed. It's been release quality for ages.
I really like sublime text, i have considered buying it several times. I go to the buy page and see the price tag - $70 US! Nope.
Given the very slow and infrequent development and the fact that its just a text editor (albeit a fancy one), i really can't justify the price.
I would consider buying if it was receiving regular updates (bug fixes, new features, etc) and had a bit of certainty with its future. But really, if it was priced around $20, i would have bought it ages ago - and if it hadn't then, I'd buy it now.
But then again, how many bugs have you found? And with it's rich plugin ecosystem, what features are sorely missing?
For something I'm going to have my face in for hours each day, every day, $70 seems pretty reasonable. (Partially playing devil's advocate here, as I use vim much more than Sublime)
Nice excuse for being cheap. Is Sublime unstable or lacking any major feature? Why the pressure of getting more regular updates if there's not anything critical missing. On the contrary, it has a lot of features, there's a massive eco system of plugins for it.
Do you use Sublime for work? If so, you should pay for it. Any other excuse is just you, being cheap. $70 is nothing for it offers.
He's not saying "I would never pay for a text editor, that's ridiculous!", he's saying $70 is just a little steep for a text editor. What exactly is it offering that makes it worth $70 vs something more reasonable?
Panic's Coda is priced similarly, but it also offers a lot of web-dev targeted features that other editors either don't provide or only provide less user-friendly plugins for
When you strip out plugins made by someone who isn't getting a cut of that $70, what are the tangible features Sublime has over the glut of free editors out there?
Just because Sublime's developer isn't updating it as much as he used to doesn't mean anything. What more could you want? The community hasn't stopped with plugin development which is what really counts.
This just reminds me of the consumer software mindset where a new version needs to come out every year, just for the sake of it. There's nothing wrong with using 'old' software that just works.