terminaljunkid

Bullshit.

Read Apple privacy policy properly. They share data with "advertising partners".

Apple sued Samsung for billions on a ridiculous patent case on rounded corners in smartphones.

Apple patented optional chaining in Swift. Although there is lot of prior art, and the thing is fucking obvious for any PL designer.

People like to shit on Google. But Apple is just more evil than Google any given day.

Common lisp was never about minimalism. It was about lisp dialects like scheme.

Mozilla particularly has really bad suit-dominant administration. Brendan Eich is here on HN. He can explain better.

I will fill in..

Google never "sells" your data to third parties. They keep the data themselves for advertisement purpose. On the contrary, apple shares any collected data with advertisement partners. Apple fanboys don't realize this.

Apart from agressive and deceptive marketing, Apple is a shitty company that asserts patents on rounded corners of phones and optional chaining in programming languages (Swift). They are objectively more evil than Google in my book.

Apparently I am biased. I would not have been in CSE if Google didn't commoditize the market. My first encounter to programming was on an Android terminal. But that's another story.

> Types solve 2% .......

Vastly understated in my experience. Even trivial python programs contain errors that could be prevented with a trivial type system like Go's

And performance. Not being fast enough is a bug. Consuming much more energy is a bug, in my book.

Sufficiently expressive type systems are better than dynamic typing. They prevent so many errors, especially in FP-inspired high level data transformation functions. I am saying this as a person who doesn't even like most of FP. (You can infer from my comment history).

Half of those things aren't even specific to FP. And I bet most people don't even use pattern matching outside HN / reddit bubble, not to say it isn't cool.

> The best stuff was all proprietary for decades.

Well, maybe. But it is hard to believe if most of those things aren't rediscovered in these decades. And IIRC that GCC took over partially because it was quite better. GCC / LLVM appear to implement every new technique in someone's PhD thesis like Diophantine equation solvers into optimization passes. I suspect it is no longer the case.

If you're saying compiler itself is slow, well the rat race among compilers is producing benchmark binaries (sadly). But given how much we have advanced, I suppose fine grained incremental compilation should be norm in every compiler.

> Turbo Pascal, too

Here I suppose you are talking about compile speeds. Well Turbo Pascal had the advantage that it was integrated with an IDE. Eclipse and IIRC visual studio can also reach those speeds using incremental / background compilation.

> We'll probably never see the source code behind any version of the k interpreter by Arthur Whitney

I have heard a about this K. What is this? Is this an array programming language like APL? I would like some pointers.

> Having portable compilers that try to heavily optimize is a mistake. Again here there are tradeoffs. People like the comfort of portability and thus don't care about small performance increments as long as code performs reasonably well. Although I would think we can have a peephole optimizer that can optimize based on target machine upon installation.

> No one seems to know what a CPU cache is!

While this may be true for normal programmer, compiler implementers care quite a lot about caches. Especially most JIT optimizations are about cache.

> Compiling to C / LLVM IR doesn't make sense.

Sure that's a tradeoff. But that allows to implement compilers in less time and utilize most optimizations.

However I too think the progress in compilers has stalled in these years. There are native programming languages being created. But it is almost Compile to C or embracing LLVM monoculture. Appreciably Go didn't do that. And due to proliferation of scripting / JIT languages, there's not much scope for optimizing or fast compilers. In particular I am sceptical of LLVM monoculture. The compilers rat race prioritizing benchmarks above other things isn't going to end well. Moreover my gut feeling is today's compiler infrastructure is not suitable for High level languages.

> "TBH if you've developed software in the past ten years, it's unlikely you haven't been hugely affected by what the FP community has been doing."

Apart from HN / reddit bubble, not many people know about FP, and not to imply that's their fault. FP is still weird, difficult for mere mortals, and ivory tower elitism is holding some of its useful ideas back.

Apparently basic phones and feature phones demised after mangolian gangster characters used it in movies.

Apple is defending themselves against the same thing happening to them again.

There is a sweet spot and for different people, that spot lies in different places.

Having a proliferation of types is bad for everyone but highest order FP Weenies among us.

People are quick to advocate anything from functional programming / academia here. Doesn't mean it would necessarily improve life of an ordinary programmer.

TL;DR I am on Windows and Go doesn't play well with its weird filesystem. It is all Go's fault for relying on highly used server OS semantics and therefore Go's simplicity is lie.

In Firefox / Chrome, tick "view desktop site" from three dot menu, and view in landscape mode.

Meanwhile me notes() { cd ~/notes/$1 clear && ls --color=always }

    note() {
    nvim $@ && clear && ls --color=always
    }

Meanwhile your Firefox suffers from really, really bad governance in a suit-dominated organization. The CEO is milking way too much from the sinking ship. The priorities are somewhere else from what people want.

I am wary of Mozilla, a completely suit-ruled shitshow that is technically incompetent because of that, as much as I am wary of Google.

If you consider hash table insertion as O(1) then it is O(n) I guess.

Dave Chiney tweeted a benchmark last night.

Will Go 2 really happen?

Generics Free, No exception handling, also hard to support to shared libraries.

That's more cost than benefit.

Support means all APIs have first class support by Google, just like how Kotlin has first class support on Android.

Fuchsia is meant to be used in variety of contexts like IoT [sic], and embedded stuff, Many time Go doesn't play well in such areas.

People coming from language like C++ and senior enough to write OSes may be startled how inexpressive Go is.

In software, many times new things come out of industry, and conference papers are (IMO) equally prevalent as journal papers.

> I am not sure if India is ready to deal with unchecked free flow of information

Fellow Indian, 100% agreed. Most of people who told me Wikipedia was unreliable now trust random WhatsApp forward messages.

That is nowhere near their goals.

Maybe if Go didn't start as a hobby project inside Google, then they /might/ even have seen some opportunity in Ocaml / Standard ML, but now that Go exists, and has a quite good toolchain, the incentive is low. Go and its foundations are radically different from a FP language like OCaml though.

Why?

On Android, there is termux terminal emulator, which allows to run native Linux binaries and already has many packages. Arguably there were other ways also before termux existed: GNURoot Debian was an app that ran a minimal Debian chroot in fake root (`proot`), Before that there was KBox. In termux also I run a full Debian chroot using proot. None of this requires root.

Even without that, static binaries could run till some recent version. I have poked with dynamic loading and LD_PRELOAD to set up my own environment which could run most Debian packages using libfakechroot && libfakeroot.

People like to shit on Android. But in terms of power user freedom, apple doesn't even come near.

> with a single one slowly pushing the rest to the sidelines.

That didn't quite happen.

> How many languages do we need again? Till you eliminate all tradeoffs in a single language, there would be new ones.

> a 1950s workaround for not having enough primary storage to keep all programs and data live at all times

Even today you don't have enough primary storage to keep your data. And even then it would require a structure when data outlives the process / application.

Most times there are no best solution, but only tradeoffs. Anyone who has done a bit of systems work knows this. And Hierarchical file system was a Ok-ish trade-off to make. Perfect is enemy of good.

> MASSIVE mistake: individual resources are neither typed nor tagged.

It comes with its own set of tradeoffs. I am a huge proponent of static typing when it comes to PLs. But in a system where multiple actors operate on shared resources, it is easy to get illusioned into a false sense of correctness. Also it imposes some extra complexity in the programming model. I am no experienced systems engineer. But someone here can address it better.

> .... entertain the cowboys who built and used it ....

You are going beyond HN standards to justify your anger against a particular methodology or people that embrace it in programming.

The universally accepted point is that Unix succeeded due to political factors (low cost and easy modification compared to proprietary counterparts), simplicity of the API, and being arguably better than others despite lacking some features people love to lament these days. But in many cases, that simplicity is a desirable thing to have. It is nice to objectively point out faults in systems. But what you did is totally dismissing some people's contributions.

It is easy to see some hyped thing and think that's the Next Big Thing(TM) after reading two fanboys preaching on Reddit, while being totally ignorant of tradeoffs.