Live data from Hacker News

IDEs we had 30 years ago and lost (2023)

blogsystem5.substack.com

21–30 of 607 posts

Re: IDEs we had 30 years ago and lost (2023)

#21

The arguments for using TUI IDEs are just very poor. Developers should not be relying on something as loaded with legacy bloat like the terminal, to do development. Zed has remote editing support and is open source. Resource consumption is a bizarre proposition, considering what abstractions the terminal has to be forced into to behave something like a normal window. Really, TUIs are not very good. I get it, I use th…

and yet zed is straight up slower than turbo c++

Re: IDEs we had 30 years ago and lost (2023)

#23
I think Emacs still does all of this; the argument the author makes is that it is "arcane", it just uses conventions he is not used to. It is however fully self-documented and interactive.

For me the best textual interface I've ever used remains Magit in Emacs: https://magit.vc/ I wish more of Emacs was like it.

I actually use emacs as my git clients even when I'm using a different IDE for whatever reason.

Re: IDEs we had 30 years ago and lost (2023)

#25
The knocks against Emacs feel unwarranted. It has plenty of colour; it has mouse support, even in the terminal, but not all terminals support it, so it's optional. It also runs in a GUI with, you know, image support and whatnot.

You can rail against its defaults, but do not make misleading claims.

Re: IDEs we had 30 years ago and lost (2023)

#26
post #5

Speaking of bloat: why are binaries from Rust or (much worse) Go so damn huge? This is in release mode with debug off. It’s weird because memory use for the same sorts of programs is not much worse than other languages. In Rust memory use seems comparable to C++. In Go there’s a bit more overhead but it’s still smaller than the binary. So all this is not being loaded. I get the sense devs just don’t put a lot of effo…

Mostly because of static linking. C and C++ don't put every library they need in the binary by default. The advantage is that a pure Go or Rust binary just works (most of the time) when copied from one machine to another, you don't have to care about installing other libraries.

That’s a great point.

Another advantage is that at least for Rust you can do whole program optimization. The entire program tree is run through the optimizer resulting in all kinds of optimizations that are otherwise impossible.

The only other kinds of systems that can optimize this way are higher level JIT runtimes like the JVM and CLR. These can treat all code in the VM as a unit and optimize across everything.

Re: IDEs we had 30 years ago and lost (2023)

#27
post #5

Speaking of bloat: why are binaries from Rust or (much worse) Go so damn huge? This is in release mode with debug off. It’s weird because memory use for the same sorts of programs is not much worse than other languages. In Rust memory use seems comparable to C++. In Go there’s a bit more overhead but it’s still smaller than the binary. So all this is not being loaded. I get the sense devs just don’t put a lot of effo…

https://github.com/johnthagen/min-sized-rust explains some of it and https://kobzol.github.io/rust/cargo/2024/01/23/making-rust-b...

Re: IDEs we had 30 years ago and lost (2023)

#28
post #23

I think Emacs still does all of this; the argument the author makes is that it is "arcane", it just uses conventions he is not used to. It is however fully self-documented and interactive. For me the best textual interface I've ever used remains Magit in Emacs: https://magit.vc/ I wish more of Emacs was like it. I actually use emacs as my git clients even when I'm using a different IDE for whatever reason.

The Magit experience is due to the use of the transient package for its UI.

Some other packages also use it. Most notably for my personal usage is the gptel package.

Re: IDEs we had 30 years ago and lost (2023)

#29
Been setteled on https://scintilla.org/SciTE.html It has simplicity + extensible for any language, you can create your own linter + highlighter

Its nothing bloated, its not embedded ide like vscode and all

Rather scite is just gui frontend for cli based binaries, it uses programming environments you have installed on your os

Just like old time on cmd or sh, we used compilers eg javac or cpp

Now scite just make it easy, its exactly same as borland turbo, you add path to your compiler binaries in scite and done you click compile or run,

Plus its lightweight and portable, carry it in usb and run on any computer by just setting paths to compiler and executor binaries

Re: IDEs we had 30 years ago and lost (2023)

#30
post #5

Speaking of bloat: why are binaries from Rust or (much worse) Go so damn huge? This is in release mode with debug off. It’s weird because memory use for the same sorts of programs is not much worse than other languages. In Rust memory use seems comparable to C++. In Go there’s a bit more overhead but it’s still smaller than the binary. So all this is not being loaded. I get the sense devs just don’t put a lot of effo…

[deleted]
Post reply on HN