Hacker News Reader

Hacker News

Comment by majidazimi | Hacker News Reader

Parent Full thread

majidazimi

When they decide to abandon:

1. Dynamic typing

2. Global interpreter lock

3. Automatic garbage collection

4. Interpreting the code (instead of compiling to a single binary).

5. Virtual machine shit

It is just the matter of time, until the team accepts the pain to learn "How to do stuff in C/C++/Rust?".

View on HN

I don’t know how you could read this post and not get this: The Atom team is quite capable of writing C++. It’s not painful at all. I love writing low level data structures in C++.

It just wouldn’t be an improvement for the vast majority of our code, because JavaScript already runs very fast thanks to V8, and using JS allows for excellent customizability by our users.

>3. Automatic garbage collection >4. Interpreting the code (instead of compiling to a single binary). >5. Virtual machine shit

When feeling like the rest of the world is running in a direction of utter madness, it makes sense to re-read "Worse is better" [1] once in a while. However, I agree, DT and GIL aren't helping anything but writing poor code faster and blinder.

[1] https://www.jwz.org/doc/worse-is-better.html

FYI: When clicked, that link takes you to an image of a testicle in an egg cup captioned with a sarcastic comment about Hacker News.

You have to copy and paste the url.

Wow, host of that site is seriously full of themselves. And of course, they own some "dance lounge" in San Francisco.

> FYI: When clicked, that link takes you to an image of a testicle in an egg cup captioned with a sarcastic comment about Hacker News.

jwz has strong opinions about Hacker News

Developers want the best quality from other industries, while in the mean time they suggest "Worse is better" for software industry. How about using the same strategy for air crafts, ships, cars, trains, medical devices? Some authority really needs to regulate software industry so every software company builds a high quality, energy efficient, crazy fast software. Aerospace people were successful to land human on moon on 1969. It is late 2017 and software industry is struggling to reduce the memory usage of a text editor to under 1GB. Retarded.

Give me $150B, the inflation-adjusted cost of the Apollo space program, and I'll put together a team and build the perfect text editor that uses "less than 1GB of memory."

Also...

> Retarded

Come on. Let's have an adult conversation here.

Sorry, but I think you've completely missed the point of this essay.

Think for a second: why can't you produce a better working text editor that people actually use, if all current ones are produced on inefficient technologies by subpar engineers with impaired judgment that led them to current choice of techniques? What are the real barriers to do that?

The same that keep people returning to $1 / 1€ shops.

Point 3. and 5. really ruin the rest of your list...

It is painful but inevitable. There is no single language that does the garbage collection great on behalf of you. However we are getting closer and closer to find smarter ways to do manual garbage collection.

Modern garbage collectors are actually okay for most workloads. "Great" is not necessary for almost all applications.

My only complaint is that if Java and .NET were AOT compiled to native code since the beginning, instead of leaving it to third parties while taking about 20 years to adopt it, C and C++ would be less relevant than they turned out to be.

Tracing GC is not an issue for the majority of applications, and just because a language has a GC doesn't mean it lacks support for value types, e.g. Modula-3, System C#, ...

Regarding affine types, while a great approach, the ergonomics still need to be improved.

The whole point (or rather, one of the points) of Java and .net are that they are NOT compiled to native code but to bytecode so that you can write code once and then run it on many different systems without having to compile it again.

One does not preclude the other, it is only a matter of distribution, like the mainframes taught us eons ago, by combining JIT/AOT on their toolchains.

The fact that Oracle, Microsoft, Google and Apple are now on the JIT/AOT train, tells it all.

To be fair, .NET always had AOT native compilation support from the early days, but NGEN is a simple AOT compiler only meant for faster startup.

Even hello world programs tend to show different performance characteristics on different OS/platforms. The idea of write once, run everywhere is over. In a moderately complex software, changing the OS/platform is a non trivial problem. Recompiling the code (which is mostly automated) is the least problematic part of it.

Are you familiar with the joys of autoconf, cmake and friends? Have you tried writing a non-trivial application that simply compiles on different flavors of Linux and Windows? Compiling on different platforms is also a non-trivial problem. Having a virtualised platform that abstracts away differences between OS makes it vastly easier to write portable applications.

For many applications running on a VM on different platforms Just Works. The idea is most definitely not over, in fact it is becoming ever more popular. Just look at the rise of abominations like Electron.

Those joys are only enjoyed for those that insist into using C with POSIX APIs covering for lack of a rich standard library.

We don't need VMs, what we need is rich libraries and there are plenty of languages with support for AOT compilation to native code with such libraries.

Something that even C++ is finally adopting.

Regarding Electron, I hope it joins MSHTML in a couple of years.

Reply on news.ycombinator.com