Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hyper 2, Electron based terminal

zeit.co

Post reply on HN
Print view View original

221–230 of 231 posts

Re: Hyper 2, Electron based terminal

#221

Post by Sean1708 »

movedx wrote: post #199
Sean1708 wrote: post #145

Earlier quoted context omitted.

> but man the 3-4GB of RAM was just crazy What kind of files do you usually work with? Because I've currently got two 10000+ line python files open which are part of a project that is at least a million lines of code, and my VSCode instance is using less than 300 MB of RAM.

I've got three Go files open and looking at all the processes related to "Visual Studio Code.app", I see a residential memory footprint of 660MB. I'm using the latest version. That also coincides with: https://medium.com/@caspervonb/why-i-still-use-vim-67afd76b4... And https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

Yeah that seems a lot more like what I would expect.

Re: Hyper 2, Electron based terminal

#222

Post by rhodysurf »

hajile wrote: post #206
rhodysurf wrote: post #159

Earlier quoted context omitted.

Isn’t it just as entitled to refuse learning something because you will only use the language you want? Even if it’s forcing a square peg in a round hole? Cmon tho, any competent engineer can switch between languages without many issues.

The basics of switching to a language in the same/similar paradigm isn't that hard. Re-learning tooling, libraries, etc takes a very long time. I can rattle off reams of stuff in the languages I know, but I'd have to spend hours searching for that same stuff in other languages.

Thats very true. The tooling and dependency part about switching sucks for sure.

Re: Hyper 2, Electron based terminal

#223

Post by notheguyouthink »

matzy wrote: post #194
notheguyouthink wrote: post #171

Earlier quoted context omitted.

I'm confused, isn't emacs in the shell? Are you saying that emacs is a gui editor? I was talking about GUI editors. I already use a term editor. I even game an example of vim/kakoune/emacs, ie, term editors.

Emacs is a gui editor. It has a shell mode, but it's primarily supposed to be used through the GUI. GUI Emacs is literally everything you described looking for above - an advanced GUI with more features than you could evere learn, yet one that still retains first class focus on keyboard UX.

That's interesting, I'll give it a look! Granted, I'm a big lover of Kakoune and vim-style modal editing.

In your opinion, what does Emacs GUI do that a terminal (or emacs in term) doesn't do well? Ie, how is it best exploiting the GUI aspect?

Re: Hyper 2, Electron based terminal

#224

Post by hungerstrike »

movedx wrote: post #195
hungerstrike wrote: post #112

Earlier quoted context omitted.

Vim isn't that popular with coders. Visual Studio and Notepad++ are the most popular across the board while Vim is preferred by Sysadmins according to this Stackoverflow survey from 2017 - https://insights.stackoverflow.com/survey/2017#technology-mo... Notice how those numbers don't add up to 100%. They let you pick multiple answers on the survey. Therefore, I would consider Vim percentage even lower in reality since…

> Vim is used by a small but very loud minority. Don't listen to them - they're optimizing for the wrong thing (keeping your fingers on the home-row of the keyboard) at the expense of just about every other aspect of computing. It would be good if you could unpack this some more and explain it in detail. If I'm wasting my time then I'd like to know why and consider whether or not I should change my practices. The par…

> if it does the same thing your hammer does...

It does not do the same thing as my hammer. Not even close. As a matter of fact, with Vim you cannot get even half the functionality of a good graphical IDE or even something like VSCode without drastically lowering your standards.

> Optimizing the wrong thing...at the expense of just about every other aspect of computing...

Vim lacks discoverability. That's the first major aspect of computing that Vim just completely throws out the window.

Speaking of windows - Vim also lacks integration with the rest of your graphical OS by default. You can't use your normal graphical file picker, you can't just drag files into Vim and you can't easily configure Vims activity to be reflected in the rest of your OS (in areas such as recently-edited-files and so on). Sure, you can get a graphical version of Vim, but now you have 2 problems - you have to configure different versions of Vim to use it the way you want to.

Even the mouse pointer a hallmark of modern computing, is largely useless in Vim!

Also, text-based configuration is throwing out another majorly useful aspect of computing: convenient and easy to access settings.

Anyway, if you enjoy editing text like it's 1976 - that's fine with me. Just don't try and tell me it's as good as my hammer because it simply is not.

Re: Hyper 2, Electron based terminal

#226

Post by terminalcommand »

whyever wrote: post #186
_o_ wrote: post #76

Earlier quoted context omitted.

Come on, what is bad and old on c++? :)

Not sure it is a good idea to use a language that is not memory safe for GUI.

We are all afraid of errors due to manual memory management, but it seems wrong to me to believe that every language that is "safe" from the memory perspective is safe.

I'd argue that in some situations interpreted languages are much more dangerous compared to a simple compiled language like C. With new "safe" languages you do not encounter an error most of the time, but when you do see an error it is quite discouraging to see that your "safe" language fails and you don't have any idea why it fails.

In order to be safe we need simplicity. We need to move the main part of the program to compilation time to have static checks. We need to write comprehensive tests on the parts we leave to the runtime. We need to check inputs at every stage.

We need to be very very careful when using concurrency.

In that matter I find the OpenBSD developers' use of C much more secure than any package on npm.

OTOH C++ is a different beast, it is complex, it has many fine-points to master.

I'd say programming in Go and using QT could be a good choice, if you're considering memory safety above all things.

Re: Hyper 2, Electron based terminal

#227

Post by nineteen999 »

techdragon wrote: post #220
nineteen999 wrote: post #215

Earlier quoted context omitted.

Hopefully by the end of the year. It's one of those situations where the emulator works great, but there's no game as such for it to interface to yet, and I'm sort of struggling to come up with basic gameplay mechanics.

I would LOVE to play around with that in the unreal engine editor just to see what cool stuff I can do with it. Please release it as a component somewhere by itself without the rest of the game. So much retro <3 for this little console you built.

I have considered that it could be useful for other people just as a component, yeah. I'm still working on the SDK to go with it (a C library and some example programs). Work has gotten really busy lately so I don't know when I'll get it done, but I do really want to finish it off.

Re: Hyper 2, Electron based terminal

#228

Post by kup0 »

I'm somewhat on the fence when it comes to Electron applications, because I do tend to prefer everything to be "lightweight" even if the machine it is on has a ton of performance overhead.

That said, I have not disliked my experience with VS Code and Hyper. I like iTerm's performance better but I aesthetically prefer Hyper. I like Sublime Text's performance far more than VS Code, but VS Code has come a long way and is free, and I don't use it enough to justify paying for ST currently.

Re: Hyper 2, Electron based terminal

#229

Post by whyever »

terminalcommand wrote: post #226
whyever wrote: post #186

Earlier quoted context omitted.

Not sure it is a good idea to use a language that is not memory safe for GUI.

We are all afraid of errors due to manual memory management, but it seems wrong to me to believe that every language that is "safe" from the memory perspective is safe. I'd argue that in some situations interpreted languages are much more dangerous compared to a simple compiled language like C. With new "safe" languages you do not encounter an error most of the time, but when you do see an error it is quite discourag…

> With new "safe" languages you do not encounter an error most of the time, but when you do see an error it is quite discouraging to see that your "safe" language fails and you don't have any idea why it fails.

I think it is very odd that you argue for C, which has the concept of undefined behavior, which is much, much worse than any kind of failure the memory-safe languages without static types can offer.

> In that matter I find the OpenBSD developers' use of C much more secure than any package on npm.

Bold claim, they still fall victim to undefined behavior:

https://www.cvedetails.com/vulnerability-list/vendor_id-97/O...

Re: Hyper 2, Electron based terminal

#230

Post by matzy »

notheguyouthink wrote: post #223
matzy wrote: post #194

Earlier quoted context omitted.

Emacs is a gui editor. It has a shell mode, but it's primarily supposed to be used through the GUI. GUI Emacs is literally everything you described looking for above - an advanced GUI with more features than you could evere learn, yet one that still retains first class focus on keyboard UX.

That's interesting, I'll give it a look! Granted, I'm a big lover of Kakoune and vim-style modal editing. In your opinion, what does Emacs GUI do that a terminal (or emacs in term) doesn't do well? Ie, how is it best exploiting the GUI aspect?

Sorry for the late reply. I'm actually a huge fan of modal editing as well, can't live without it, so I use evil - and it's perfect. GUI emacs does everything that any other IDE does, and that's what I like so much about it. With vim or any of it's GUIs, normal IDE features feel like "duct tape" on top of the program. Whereas, emacs was meant to be used in this context. I mean, for example, when programming in C I can even use emacs to debug (it has a GUI for gdb). And those kind of advanced IDE features are available for any language. Not even touching the fact it's just a lisp machine and you can build any kind of program you want in it, it takes extensibility to the next level with a lisp dialect that's relatively easy to learn, whereas extensibility in vim is limited to googling for vimscript code someone else wrote (unless you take the time to learn vimscript shudders). Emacs gave me everything you said you were looking for, at a time when I was looking for those exact things. I wanted a modal editor like vim that actually was an IDE, had IDE features, and was completely extensible. Emacs checks all of those boxes.

If you're a vimmer and want to start out with emacs, try spacemacs. I used it for a year before building my own emacs config. It's an incredible program, won't take you long to get running if you're used to vim, and after a week I'd bet you'll have a hard time going back to gVim.

Post reply on HN