sacado2

The study you're probably talking about focuses on hospital survivors, not on the broad group of "naturally infected people".

This is probably a bit overkill for that kind of problems. In Anaconda, the problem is probably that the instance isn't described optimally. In real life (that is, unless you make it up and artificially find the worse possible example), package configuration / management is not considered a "hard" SAT problem (but an "industrial" one, i.e, still NP-complete, but solvable in a reasonable amount of time in practice).

"Hard" problems are those you don't expect to solve in a few minutes on a desktop (or laptop) computer.

Yes, because the examples you give already have a solid reputation.

You can get away with it when you are "the government .gov", but if you are "small start-up.com" and I want to invest in your risky stocks and all I get is an "Oops page" when I want to know a little more about your dividend policy, I'm gone.

A huge, 2-decades gap. Way too late, because in the meantime, Turbo Pascal had been developed and made the language practical (and btw I'm still impressed by the quality of TP's "IDE" for the time), and in 1990 you had several competing standards that split the community, between original "academic" Pascal, Turbo Pascal, Object Pascal, ISO Pascal, and a little later Delphi. Add that to the fact Wirth himself had lost interest in the language for a long time and had developed several better ones (Modula-2 indeed, Oberon too).

But then ISO Pascal is not 50 years old, far from it.

The Pascal from 50 years ago was not that great in practice.

Go is starting to get a bit old though. Version 1.0 dates back from 2012, 9 years ago. It's as old and mature as Java was in 2005.

Even better, in practice we have amazing tools nowadays that can solve practical NP complete problems in a reasonable amount of time (I mean, optimal solutions, not OK-ish ones).

It's all about technique and the style you want to develop. Two singers can have very different voices too.

Last time I used NPM, it tended to download megabytes of dependencies for each project. If you used a package in, say, 10 different projects, you had 10 copies of it. Did they solve that issue?

> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds.

Put everything you don't want to manage into Rcs, RefCells, Boxes and the like, and you'll more or less feel like you're using a (verbose) GCed language (with a loss of performance and safety as a natural consequence).

> I enjoy Rust and have been writing it for quite some time. However, I feel like server side languages still have a long way to go. Client-side languages in comparison have been only growing better

The fact you call them "server-side language" is a strong bias. Not everything is a client/server app.

Yes. I think Zig is a safer C, while Rust is a safer C++. C programmers will be more excited by Zig than by rust, and the opposite is true for C++ afficionados.

The problem is, you can't know in advance whether a given piece of code will ever need to grow in the future or not. I've seen way too many "one-off POC prototypes" eventually be used in production because they did the job. And then they need to be updated / extended a few months later "because we should deal with that new corner case too, now".

The soft I have the most performance issues are Firefox, LibreOffice and Aperçu (don't know its original name, but it's called that way in French -- Apple's PDF viewer). All of them written in different, non-GCed languages. Usuall the problem is abuse of abstraction layers, more than abuse of a GC. And your javascript examples are a good example of that. GCed languages tend to abuse dynamic allocation and dynamic dispatch, even when it's not needed (there is more garbage to deal with).

However I agree the idea only a few software need to run fast is bullcrap.

It reminds me of the good old C++ times, when people were scared OOP would make their programs unacceptably slow because of virtual functions. That's why methods are not "virtual" by default, which led to nasty bugs when you were actually relying on polymorphism and forgot to declare a method virtual. Those were the days.

But there's a cost induced with this superior productivity, and it's not only about speed. Maintaining and updating these (dynamically typed) programs in the future feels way less productive because things start to break everywhere, unless they've an extensive test base and use modern features like type annotations -- but then, you start losing the productivity advantage you had in the first place.

> Then how come everything is so ridiculously slow these days, despite faster computers?

As you said, it's usually not a GC issue. Many of these ridiculously slow programs you talk about are written in C++.

Don't forget good old Ada.

Why don't you write a book called "rust gotchas: 4000 subtle ways rust can try to f*ck up with you and how you can defeat it"?

I'm (almost) serious (if you do that, do several, specific titles: "100 lifetime gotchas", "100 traits gotchas", etc.) I've read several books that were little more than short blog posts collections, with a common theme but no real overall structure, and, mind you, some of them were pretty good despite of that, because they solved real problems I had. Some people learn better with a bottom-up approach (i.e seemingly random sequence of independent items that eventually let you grasp the big picture) than top-down (3 parts, with each part having 3 chapters, with each chapter having 5 sections, with each section having...)

> 2) Started getting good consulting projects 3) Started getting Royalties(Passive income)

Yes, I think technical books are a great marketing asset when you're a consultant / freelancer. It gives you a ton of credibility, more so than one more project to your cv / portfolio. Plus, as a bonus, it provides a few royalties. It's a good way to stand out, too: "Do you have a business card so that I put it with all the other business cards I got today and will forget as soon as I get back home?" "No, Mr. Prospect, but let me give you that book I wrote, you'll enjoy it, and you have my contact info on the first page".

Rather than a potential source of passive income, I tend to see it as a marketing tool that has a very low to negative cost. Seen that way, most of your cons aren't that bad.

If I were a freelancer / consultant, I would definitely write books.

Thank you! I didn't know about the `=n` syntax.

The worse bug I fought in one of my rust programs was when using the range type. I needed to go from n to 1 included, so, from n included to 0 excluded. Of course `(n..0)` didn't work, so I tried `(0..n).rev()`, which didn't work either (first, you generate all numbers in [0;n-1], then you reverse the list), and I can't blame the language, it makes sense, but it's highly unintuitive (in python for instance, `range(n, 0, -1)` does what is expected).

I'm not a seasoned rust programmer though, is there a better, more explicit way to do what I attempted there?

Are we talking about semver in general or semver the way it is (supposed to be) used in go mod?

I'd be glad to be presented a real-world counter-example in a (non-toy) go library.

> Just what is a breaking change anyway?

It's just an API kind of thing. If a function / constant / var / type was available and is not anymore, it's a breaking change. It's an objective measure, there is nothing left to subjectivity.

Now, of course a bug fix is going to "break" things if your code relied on the bogus behavior. An updated algorithm can also break things (I maintain a SAT solver, whenever I update the underlying algorithm, even if it's way faster on average, in some limited cases it can make one very specific problem way slower to solve, which can have bad consequences). But as it has no consequence on the API part of things, it's not a major change in semver's meaning.

> ADA has proper arrays, with bounds checks.

Not only that, but you can also opt out at compile-time if you need, for performance reasons.

You also have (optional) runtime bound-checking for scalar values (aka "integers"), and you can even specify the bounds yourself (like "A number between 3 and 17").

It's a well known psychological phenomenon though. Losing a given sum of money is more painful than earning that same amount. if you find a $20 banknote on the sidewalk, you wont be as happy as the guy who lost lost it is pissed off.

> The fact that they use the same compiler is to me a devastating argument.

GCC can also compile Ada. Would you say C/C++/Ada is a single language?

Are they going to make non-backward-compatible changes, or is this just a marketing move?

I learned programming before I learned English. I was always confused by PRINT vs INPUT: which one reads and which one writes? So yeah, it could have been grob and bolver or anything.

A C++ function declaring several uninitialized pointers one after the other is very suspicious anyway. It looks like the programmer is trying to write old-school (pre C99) C code (declaring all variables at the top of the function) in C++.

Typedeffing pointers, especially for the sole purpose of "being less verbose" when declaring uninitialized pointers, is a red flag too.