F-0X

>They deliberately ignored proven concepts in programming language design

Not really. Generics, as a standalone feature, is not useful for much more than just container types. Go has generic container types, so woot, no need for plain generics.

Languages like Haskell which utilise generics for more useful things do so with other features. In Haskell's case, it's typeclasses, in other languages, it might be operator overloading. If you have a type T, you can't do shit with it unless you know something more about it. A type T that has a notion of + though can be checked at compile time and functions can "add" generically.

Well Go has interfaces. You can stick an Add() method on all the structs you might want to pass "generically" to a function, and add them.

So indeed, Go certainly is much simpler for having skipped "proper" generics, since they get to skip all the complicated stuff that makes them actually useful.

>GO syntax is very regressive comparing to where we hopped programming languages should go.

Speak for yourself maybe, but I appreciate Go's overall style. You also mention Rust and Scala in your post. If that is to be the future of language syntax, I should quit.

Because it is not objectively unethical.

Site comes up blank for me (Palemoon).

That's not what was said _at all_. You simply have not read the post correctly, and worse, your phrasing exaggerates the actual situation.

>On the other hand, it is rapidly getting very complicated

This seems to be the case for almost any "C replacement", and it will be (my prediction, at least) the reason they all fail.

I feel I might be a bit of an outlier in this respect, but I have only ever enjoyed using languages which are small and simple - C, Go, Scheme. The times I've tried Rust, it's been nice to have code that cannot segfault, but I find it such a chore to deal with. Whenever I've read open-source projects in Rust it's always a readability disaster. Also the compiler emitted warnings because functions were not snake case, which I found obnoxious.

But that's just false. Rotations preserve orientation, reflections do not. They can't be equivalent. Two reflections can be equivalent to a rotation however, because that restores the original orientation.

I disagree on the basis that a hacker news account has no intrinsic ties with a personal identity.

It also has no notion of relationships between users.

I just need to say it. Thank you for putting types on the left.

Me too. The laptop is an inch thick, and _I love it_.

We need a revival of bauhaus design - no distinction between form and function. If it falls short at its function, it fails as a form, and should not be accepted.

> In general, cut back on foods and condiments rich in salt, sugar, fats

Another way to say this is "eat bland food". Literally.

Salt, fats, sugars, and acids, are what make food taste good. These distort your taste palette? These _are_ your taste palette...

I'd have lost all respect for them as a developer in that moment.

> Most of Europe and the rest of the Anglo-sphere will happily move to plant-based proteins and completely leave that industry behind

I really doubt that.

Sea water is very salty, and will box your kidneys in. It's not the same at all.

If these have a dehydrating effect, it will be (literally) drowned out by the amount of water consumed. It will be a vast net-positive.

> it might not happen until weeks into production.

It should never happen in production - there should be a test that proves this.

Seriously, you should learn Lisp instead.

>The human voice is the ultimate instrument.

I strongly disagree. A voice is so limited in every single way. There is so much more that can be done with a proper musical instrument, especially those capable of multiple simultaneous notes. The piano is a good example.

An _acceptable_ python!? More like Python is an unacceptable Racket.

Racket is an absolute joy to use.

The problem with this is that it misses the point of most cli programs, which is that they are to be composed with other programs.

Besides, when colleagues of mine decided to demystify the command line and learn it proper, they're always surprised how much easier it is than they expected.

The GUI/CLI gap, as far as I have seen, is one of willingness to invest some time to learn.

> Tried using man pages but they're always slower to find stuff in

Man pages are presented through less, so you can begin a (regex) search with / and hit n to go to the next result or N to go back.

If you knew this, I am actually very surprised you don't find information near-instantly.

> There are lots of overlapping technologies in our space and learning all of them is a huge time waste

I agree.

That's why I invested time into looking at Go over Rust.

Go will be the better choice for most programs most developers will write. Go 2 even more so. Rust is too complex, and for the applications where a garbage collector is acceptable (>99% of them) it isn't worth it.

Strong disagree. HN is not a social media. Because we do not use it for social purposes. This site has no concept of user relationships, and it does not encourage you to use real/identifying information about yourself to use it. It is centred on topics and discussion - sites like this, Reddit, and other forums can develop social networks, but this is a byproduct and not the intent, which I think is the single most important factor. HN's purpose is not to keep you in touch with your friends or community, thus it is not a social media.

I quite strongly disagree. My favourite languages, Scheme, C, Go, share precisely the "small and focused" philosophy, and its a big reason why I like them so much. Your point about javascript is not very strong either, I imagine the real reason is its origins as a browser-embedded language meant that the same style of imports in Node.js were not feasible. Even if this is not true, I would then shift the blame to the implementor of Node.

Scheme in particular deserves so much more attention, it is so capable and it is a joy to write.

>Personally, though, my main criticism of LaTeX is that its logic is static and based in plaintext.

Literally the best feature. Universal, easy to manage with text editors, text processing tools, version control, etc. The future should be going back to this, imo.

>The future is in interactive documents (e.g., in the direction of [Wolfram's][2]), not statically compiling plaintext to image-like documents.

Jesus I hope not. Text is and forever will be the superlative format for information - images and videos can be brilliant for aiding the understanding of new ideas, but they are awful as a reference. You can search text, you can't search for images or within a video. And those are not problems to be solved - things should just simply be in text.

Why specifically Qatar?

On the other hand, I don't know who these articles are really for. I have _never_ met a developer who struggles with git. Not many claim to understand it deeply, but all can rebase, cherry-pick, use the reflog, etc. and almost never do they run into issues.

It mystifies me. Git isn't hard, nor complicated. "Checkout" has a few too many meanings, and thats the singular gripe I have with it.

> That's like 10 lines in Python and much easier to read and test.

It's a single command in bash, invoking a program far more efficient than anything you can put together in python. It is literally a tool written for this exact purpose. I think it is simply ridiculous to not use a pre-existing tool that frankly you cannot out-do with a scripting language.

Even if you are writing a python script, you should _still_ use find to search for files if there is _any_ complexity in the search requirements.

> Diverse teams gather more information which leads to better insight of edge cases, and ultimately to better products.

This is just an assertion currently, and I am not inclined to believe it is true. I would believe it for more "people" and/or culture oriented problems, such as catering, but for the majority of software development problems, diversity in people is nothing compared to diversity of software development experience. Which, ironically if we take as given most developers are white males, we maximise on average by only hiring white males!

The general case of eigen-things has no other term to describe it. One might want something that hints at the geometrical meaning of eigen{values,vectors} when they learn about them in the context of multiplying vectors by matrices, but ultimately the concept is a mainly algebraic one. Accepting this it becomes easy to deduce what should be meant by "eigenfunction of the differential operator". So I think, somewhat retroactively, "eigen" is the best word to use there.