Live data from Hacker News

IDEs we had 30 years ago and lost (2023)

blogsystem5.substack.com

11–20 of 607 posts

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

#11
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.

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

#12
I used Borland Turbo Pascal in 1984. It was amazing to work with something so fast on a PC that was really so slow. No IDE/Compiler since then matched the speed. Today's code is massively more sophisticated and complex, so there is no way to match that performance today despite the speed of computers today.

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

#13
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.

Go especially, on some platforms they go straight to syscalls and bypass libc entirely. They even bring their own network stack. It's the maximalist plan 9 philosophy in action.

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

#14
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 the terminal all the time and I will edit files with vim in it, but it is a pointless exercise to try to turn the terminal into something it was never meant to be and try to have it emulate something which would be trivial on a normal OS window. To be honest it makes me cringe when people talk about how much they perform tasks in the terminal, which would be much easier done in a graphical environment with proper tools.

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

#16
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…

Rust doesn’t strip debug info by default.

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

#17

I used Borland Turbo Pascal in 1984. It was amazing to work with something so fast on a PC that was really so slow. No IDE/Compiler since then matched the speed. Today's code is massively more sophisticated and complex, so there is no way to match that performance today despite the speed of computers today.

I got a windows 95 66MHz Pentium machine with 16MB ram at a yard sale in 2002. Visual Studio 5 Enterprise worked plenty fast on that with features I still miss (or which don’t perform as well) in modern environments.

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

#19

I used Borland Turbo Pascal in 1984. It was amazing to work with something so fast on a PC that was really so slow. No IDE/Compiler since then matched the speed. Today's code is massively more sophisticated and complex, so there is no way to match that performance today despite the speed of computers today.

totally. so strange that that was the fastest, most flowy dev experience i've ever had. been chasing that ever since. though i must say rails, vite, react fast refresh, etc. are pretty nice in that regard.
Post reply on HN