Live data from Hacker News

Sunsetting Atom

github.blog

651–660 of 880 posts

Re: Sunsetting Atom

#651
post #436

Earlier quoted context omitted.

There are some things worse than death, like what MySQL experienced: being turned into a zombie designed to eat the brains and infect people who used to use it when it was truly free, all in the name of tricking people into switching to Oracle's expensive SQL server.

MySQL has been and continues to be a major success for Oracle, and in 8.0+ and beyond the feature set, correctness, and performance have improved substantially; MySQL continues to evolve and currently is in a good spot. It is even more attractive in modern times thanks to systems like Vitess, which add major features (online schema change, excellent horizontal scaling) that give alternatives a run for their money. Wh…

Then explain MariaDB?

https://www2.computerworld.com.au/article/457551/dead_databa...

>Dead database walking: MySQL's creator on why the future belongs to MariaDB

>MySQL's creator, Michael "Monty" Widenius, is scathing on database's future with Oracle

>It's fair to say that MySQL creator Michael "Monty" Widenius is not a fan of Oracle. When the company announced in April 2009 that it was purchasing Sun, Widenius saw a bleak future ahead for the (still) wildly popular open source database, which Sun had snapped up in 2008.

>The day the Sun purchase was announced, Widenius responded in the tried and true open source fashion — he forked MySQL, launching MariaDB, and took a swathe of MySQL developers with him.

>"Many of the original MySQL core developers, including me, didn't believe that Oracle would be a good owner of MySQL and we wanted to ensure that the MySQL code base would be free forever," Widenius explains.

>Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB

>Widenius and a number of other MySQL developers started a company, Monty Program Ab "to provide a home both for MariaDB — the new MySQL — and for all MySQL core developers".

>"Monty Program Ab is owned by the employees and uses the 'hacking business model' as a way to drive the company," Widenius says.

>Although MySQL is still widely used — Db-engines.com ranks it as the third most popular RDBMS after Oracle and Microsoft SQL Server, compared to MariaDB coming in at #35 — Widenius still believes the database has a bleak future under Oracle's stewardship.

>Oracle's treatment of MySQL and its community since its purchase of Sun has proved Widenius' original fears correct, the developer says. Not mincing words, Widenius says that Oracle has made it clear "that they have no love for open source, working with the community, or MySQL in general".

>Widenius cites as examples of Oracle's disregard for open source principles the September 2011 announcement of commercial extensions to MySQL, the bugs database not being public any more, and a lack of test cases for new code in MySQL 5.5 and 5.6.

>Widenius is also scathing of the quality of Oracle's MySQL development efforts. "Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB," he says.

>He also says that security issues are not addressed quickly enough.

>"Instead of fixing bugs, Oracle is removing features," Widenius says.

>"The MySQL documentation was never made open source, even [though] it was promised in the MySQL conference in April 2009," he adds.

>"Flagship features promised for MySQL 6.0 have never been released, even if they were fully developed and ready to be released," he says, referring to online backup for all storage engines and foreign keys for all storage engines.

>"Most of the original MySQL developers have left Oracle. Without people that can understand and explain the code it's almost impossible for Oracle to develop MySQL further even if they wanted to."

>As further evidence of disdain for MySQL users, Widenius cites what he describes as "sharp" increases in licence and support fees, a lack of an open roadmap and no way for the community to participate in the database's development.

>"Why is the price for a MySQL OEM license higher than for Oracle Express?" Widenius asks.

[...]

Re: Sunsetting Atom

#652

Earlier quoted context omitted.

Interesting! I just wanted to let you know my perspective, which is probably quite unique. I started using atom pre-1.0, a long, long time ago. I immediately jumped to vscode when I realised it existed. The reason is a bit weird; it's the find-in-files/project (c-s-F/Ctrl+Shift+F) sidebar search/replace feature. Compared to the Atom (and from what I can see in the youtube talk, zed has the same "problem") which opens…

> I code mostly in domain-specific, esoteric, private languages, no stdlib or docs, and no online resources to learn from. Jesus, who are you?

Writing DSLs is not uncommon among Lisp developers.

Re: Sunsetting Atom

#653

“Sunsetting” an open source project seems… unfitting? Hand it off to the community, look for new maintainers, donate it to the Apache Retirement Home for Veteran Projects, sure. But saying that you’ve decided to “sunset” or “archive” it, telling users to plan for their migration, seems counter to the notion that open source software forms part of a commons - something that Github, of all companies, should understand.

GitHub is owned by Microsoft, the company that invented "Embrace, Extend, Extinguish". We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".

Like when they sunset the closed-source .net framework and created the open source .net core?

Or when they sunset the closed-source PowerShell and created the open-source PowerShell Core?

Like those?

Re: Sunsetting Atom

#654
post #416

Earlier quoted context omitted.

> Emacs, vim Unlike VSCode, Emacs and Vim have a learning curve. And turning them into full blown IDEs makes their usage even more complex. > Sublime Sadly, Sublime is sort of dead. > TextMate TextMate: Text editor for macOS

> Unlike VSCode, Emacs and Vim have a learning curve. That's not the point, we were talking about plugins.

I think that the learning curve might be in reference to installing plugins.

Installing an extension on vim (never done emacs) is something that does not just happen easily. There is no intuitive search for extensions built in, you likely have to install software that manages your plugins.

VSCode on the other hand rarely requires more than a single click through a built in interface.

The plugin ecosystem exists for command line editors, but it definitely has a learning curve

Re: Sunsetting Atom

#655
post #644

Can someone explain the hype around VSCode to me? I looked into it about a year ago and was immediately turned-off by the overwhelming amount of features that they throw at you right in the 'beginner's tour'. What I appreciate about Atom is that it is very simple right out of the box and does not get in your way. You cold always beef it up with packages later, but that progression is much more pleasant to me than the…

The killer feature of VS Code for me is that when you open a source file for python, or C++, or whatever it pops up a dialogue: “would you like to install the extension for this file type?”. Click that and you’ve got working IDE features for that language with none of the hassle of tracking down which is the right extension, how do I keep my plugins up to date, which dependencies do I have to install first, etc.

In my experience, it works up to the point where it installs the extensions, and then it does a bunch of processing and still can't figure out how to run the project or what the code means anyway. Plus I now have a slew of new extensions installed, and I'm not sure which are new looking in my list of extensions.

IntelliJ has a pretty damn good track record for me, when I import a project it indexes for a minute or so, then it automatically knows the entrypoint to run the project, and has a fantastic understanding of all my code. Cmd+click any symbol and it can show me definitions, usages, implementations, etc. I can hit shift+F6 to rename a symbol, and it hits every usage perfectly (as opposed to every time I've tried to use VS Code to rename something, and it just causes me more problems than if I were to do it manually). I haven't found any other text editor or IDE that works as seamlessly in this regard, and it's a dealbreaker for my productivity.

Re: Sunsetting Atom

#656

Earlier quoted context omitted.

How do other editors/IDEs perform in terms of accessibility? What are your favorites?

My favorite is VS Code by far. I use it daily. They recently also added a bunch of sound cues to help figure out if code is folded or a line contains an error. It's pretty great. Auto completion reads well, the parameter hints read, even the built-in terminal works. So overall I'm really happy with it.

Would you mind commenting on XCode? I heard that Apple really cares about accessibility.

Re: Sunsetting Atom

#657
post #615

Earlier quoted context omitted.

"It's not open source, it's code licensed as open source". Hmkay... I find it impressive how concisely you're contradicting yourself in that sentence.

The project is not open source. The code it releases is open source. There's no contradiction - it's perfectly normal for a company to release their code under an open license; Chromium is another example of this. It's technically open, but for almost every practical purpose it could be closed and it would make no difference.

What you're trying to say is "I don't like the way it's run". Okay, fine. That doesn't make it "not open source".

I have projects where I don't accept patches. "It works for me" and I just don't feel like reviewing patches. Is that not "open source" in spite of being MIT licenced?

"I can do with the code what I want" is the entire and only point of Open Source and Free Software, something Stallman and many others have been pretty clear about over the years.

Re: Sunsetting Atom

#658

Earlier quoted context omitted.

GitHub is owned by Microsoft, the company that invented "Embrace, Extend, Extinguish". We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".

When this inevitably happens to VSCode, I'm sure we'll all flock to Sublime Text in droves (or some hip new editor on the block). Contingency planning for this could be a small but wise time investment for dependent teams. VSCode could very well go the way of the Do... Docker.

> When this inevitably happens to VSCode, I'm sure we'll all flock to Sublime Text in droves (or some hip new editor on the block).

the normalization of this behavior within the industry makes using emacs or vim even more satisfying.

it's nice to having an unchanging cement foundation to stand upon once-in-awhile.

Re: Sunsetting Atom

#659

Founder of Atom here. We're building the spiritual successor to Atom over at https://zed.dev . We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting. Here's a talk I gave l…

"Mission-critical tools should be hyper-responsive." Did not seem to be important with the worlds slowest dev-tool ever, Atom. ;)

"Real-time collaboration produces better software." At design level, ok. Programming is in most cases not a co-op operation. If it is, then you are probably creating solutions while writing code which is the best guarantee for bad solutions.

“Conversations should happen close to code.” Agree to some degree, this is a big flaw with GIT. It is also a flaw with many programming langs and tools. Even if I use collaboration features in VS and VSC many langs are simply not designed for presenting code to people not highly familiar with the specific code base. So, an editor may not solve the problem here.

“Your editor should disappear.” I mainly code in VS and what I can do in VS in 10 mins takes me a couple of hours in VSC. A tool should aim to be the default of a problem. The amount of time I have seen wasted over the years with people trying to master VIM or git from a prompt is just ridiculous.

Re: Sunsetting Atom

#660
post #165
post #2

It's what kickstarted Electron which eventually gave us VSCode, Slack, and lots of HN comments about memory usage. It also had the sweetest default theme of any code editor. RIP.

Electron is both an amazing enabling technology, and also an artifact of the sad state of affairs for computing platforms. One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms. Instead we ended up in this bizzare world where if you want to maintain a desktop GUI app, you either need a large team to sup…

I'd describe it, together with Docker, as good solutions for problems we shouldn't have anymore
Post reply on HN