fredmorcos

> So what should we use instead of signal?

Threema is one alternative.

This comparison is laughable and ignorant.

So Go was designed for toddlers?

I worked for a company where the founder thought everybody should use the same tools (meaning the tools he used: OpenSuse, KDE, VSCode, etc...) so that we can help each other and, like you propose, we wouldn't have to fiddle with anything since he would provide configuration for everything.

I've had plenty of problems running this garbage, and everytime he wouldn't help and would just say something along the lines of "what did you do? I've never ever had a problem with it".

If you think VSCode or any other tool doesn't need fiddling then you haven't pushed that tool beyond the basics.

Use what you know and what you're comfortable with. Sometimes VSCode is lacking at things where Emacs shines and vice-versa.

> I'm using Arch Linux and it's the most stable operating system I've ever used.

lol

(from an arch user)

A garbage collector of obviously lack of magic.

That's what they tell you.

> Generics are a tail abstraction. Its the last abstraction that you are able to make to your code to reduce boilerplate. This usually means that is the least useful and in generics specific case the boiler place it reduces is minimal.

This is absolute and utter delusional nonsense.

> This also prevents errors being dropped by accident.

Instead of designing a language that prevents errors from being dropped by accident, hire a bunch of literal gophers to search your codebase for inverbosity. Good plan will work 10/10 times.

> And things like the lack of abstractions and generics are what create a community that's less reliant on dependencies. "A little copying is better than a little dependency" and you can see it in stark contrast to something like the JS community with its require('left-pad') NPM ecosystem.

"A little copying", "less reliant on dependencies"... do you even vendor bro

> While not objectively a bad thing, that's at the crux of the problem many have with Go: it sets the bar very, very low for getting in your way instead of trusting you to be even slightly competent.

And there's nothing wrong with that, that's exactly Go's target audience.

> I tend to specialise in the sort of software infrastructure-y problems that are usually solved through code.

So basically a coder?

> Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't.

I guess because it does not merit that adoption. The only reason it gets attention at all is either 1) "oh it's made by the same people who made UNIX and C and UTF-8", or 2) "oh it's made by Google".

(I'm going to ignore the personal attack and insult)

> If you want to talk figuratively, making mistakes does not constitute having your "head up your ass." Even making multiple mistakes doesn't warrant that kind of statement.

Making deliberate mistakes multiple times and resisting fixing them for 10 years does qualify as having their "head up their ass" (or asses if that's what you prefer).

> Generics are slower, that's the trade-off. Developer time vs. execution time.

You have no idea what you're talking about.

> Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that.

No it's not disrespectful, it is entirely true. Do consider the origins of Go, where it all started as an experiment in combining bad decisions into a single programming language to see what would happen. What those very people didn't realize upon releasing it to the world is the sheer amount of people who fell for it, it was supposed to be a joke, with a stupid looking mascot and all... Now they have to take it seriously - and Google has to choose between keeping it alive or getting a forever bad rep for killing it - because too many companies rely on it, and they are forced to retrofit useful features on top of the giant pile of garbage they've created.

Could be. I don't know which one came first.

strtok is there for things like and similar to /etc/hosts and /etc/fstab

VS Code takes ~6 seconds from clicking its icon to having its window show up. On an 8th-gen Intel i7 with an SSD. Yes Electron has abysmal performance.

I don't want to be defending Rust but your post has so many misconceptions. May I ask where you got all that information and what your background is?

> C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that, nor does it have a stable ABI.

Rust has #[no_mangle] and extern "C" and those two guarantee that ABI stability you're looking for.

> Then furthermore, a vast amount of effort has been put into these tools over the last years to ensure that they run on any *nix and any architecture, and even so they can be ported with relative ease.

That's actually a breeze in Rust, including cross-compilation (which is relatively painful in C/C++).

> For example, how do you suggest implementing glibc in Rust? You might argue "why would we need the C standard library when we're porting things to Rust", and the answer is that if you want to make a move towards rust, having a C library (particularly the GNU one, a lot of software depends on GNU extensions) is of utmost importance until that goal has been achieved.

There's work towards that: https://gitlab.redox-os.org/redox-os/relibc

> From a point of view of postmodern c++, rust has little to no advantages left.

My entire adult life I've been writing C, I resisted Rust for a while but took the plunge when a C++ project came along that was in dire need of being reworked. I liked it, the language and the compiler and tooling around it helped me tremendously.

I assume you're aware of all the things that Rust statically guarantees for you, and I'll also assume you know the difference between language complexity and language implementation complexity (eg, the compiler or some other tooling):

I've been skimming through the C++ section of cppreference.com, and oh boy, there's heaps and heaps of... stuff... just stuff. The interplay between all that stuff is complex and it's hard to keep everything in mind. Keeping things in mind is important for correctness, or at least for having a reasonable amount of confidence in what you're writing. Information locality is also important for correctness, and C++ lacks both of those. I'll even go further and say that C++ is a write-only language, like a garbage bin of features and exceptions to each of those features. Rust has many many many clear advantages (and some disadvantages) compared to postmodern C++.

Can someone explain why this is better than branch, commit and rebase from master if needed, then submit the pull request?

When you search in the API documentation, you will find 3 tabs at the top: "In Names", "In Parameters" and "In Return Types".

Example: https://doc.rust-lang.org/std/?search=option

I just think it's the opposite. Those without constant distractions and expenses end up being more productive and richer.

This is gold! Thank you! :D

> Sure 4.0 was stated as a Beta and every distro put it out (When KDE stated it wasn't ready for that) and everyone Nuked KDE till about 4.7.

KDE put it out, everyone complained it was terrible, unstable and not ready, then KDE called it a beta.

> can be changed by 'f' because mentioning the 'x' object name in a function call may implicitly converts to the address of the object

(1) They are two different types and (2) it's clear to you at the calling site!

> Are we talking about the same language here? The language where arrays implicitly decay to pointers, where integer types get implicitly promoted all over the place, where aliasing rules implicitly define which pointers can and cannot alias, where partial initialization of a struct or array implicitly sets the other members to 0? Where the language will let you call an undeclared function and make up a prototype on the fly for you?

-Wall -Wextra and those issues are made clear to you. But granted, that's part of a good compiler and not part of the language.

> I also don't understand your C++ example, without side-effect why would both invocations of f() within the same scope produce a different result? I thought you wanted to criticise function overloading but you call it with an int both times so I don't see what's you're getting at.

I'm not criticizing function overloading.

> Or maybe you meant that the two calls are in a different scope and could resolve to a different function? But you can do that in C as well in two different translation units and making two static f() implementations.

Yes the two functions are different, but not necessarily in scope, they don't necessarily need to have the same names. Yet at the calling site they look exactly the same: one will modify your data without you being aware of it and the other will not, and there is no syntactic hint to differentiate them.

What does this have to do with syntactically expressing the same thing twice with two different semantic meanings?

So you get my point. 'x' is not going to be modified behind your back and it's pretty clear on the calling site. In C++ it isn't clear.

Agreed. But my example isn't about security or UB. It is about the language allowing you to write two IDENTICAL snippets of code that end up meaning two different things without any overloading involved. Like saying something and meaning something else.