As a veteran of a large scala project (which was re-written in go, so I'm not unbiased), no. I was generally not happy.

This was scala 2, so implicit resolution lookup was a big chunk of the problem. There's nothing at the call site that tells you what is happening. But even when it wasn't hidden in a companion object somewhere, it was still difficult because every import change had to be scrutinized as it could cause large changes in behavior (this caused a non-zero number of production issues).

They work well for anything you would use environment variables for, but a chunk of the ecosystem likes to use them for handlers (the signature being a Functor generally), which was painful

> There's nothing at the call site that tells you what is happening.

A decent IDE highlights it at the call site.

It's definitely an abusable feature, but I find it very useful. In most other languages you end up having to have completely invisible parameters (e.g. database session bound to the thread) because it would be too cumbersome to pass them explicitly. In Scala you have a middle ground option between completely explicit and completely invisible.

I'm not sure what you consider a decent scala ide, but it was a problem with IntelliJ in several of our code bases, and I'd have to crawl the implicit resolution path.

I eventually opted to desugaring the scala completely, but we were already on the way out of scala by that point

> it was a problem with IntelliJ in several of our code bases

It shouldn't be, unless you were using macros (always officially experimental) or something - I was always primarily an Eclipse guy but IntelliJ worked well. Did you not get the green underline?

yeah that's what i thought, but maybe scala implicit param not being perfect will help finding a better linguistic trait (maybe they should enforce purity on these parameters)

IMO it is perfect, or at least better than anything else that's been found so far.

"Purity" means different things in different contexts. Ultimately you can give programmers more tools, but you can't get away from relying on their good judgement.

thanks a lot for your answer

> however I will note that a large reason that C exists in the first place was to have a machine independent language to write programs in.

That's fair, but what we call a monstrosity by modern standards is much simpler than porting the assembly

There were cross plaform languages before C, but they never really took off for system development the wat C did (OSs, for example were commonly written in pure assembly)

A side effect of C not having a price tag associated with it, anyone with UNIX source tapes got a C compiler for free, until commercial UNIX became a thing, and splitted into user/developer SKUs, and thus GCC largely ignored until then became a thing worth supporting.

> reflect: what does seeing “written in rust” as a suffix make you think about a project’s qualities before you ever read the code

That the community is going to be significantly more dramatic than average

That's not giving up in the sense it's being used here. Giving up would involve no longer attacking the problem, not switching tactics

They made medical claims. That's a very bad idea if you aren't 100% sure

Forget that. Pasting logos of big-named companies on forged documents. I mean, seriously?

There are lots of organizations with $1M and a desire to influence the population

This can only be done with a sentiment that was, at least partially, already there. And may very well happen naturally eventually

> You got any idea why people hate the concept of nested functions in C?

It breaks the model of c mapping to the hardware.

Functions in C are just labels you jump to. Assuming you want to capture values from the environment you're defining the function in, you have to implement some sort of function struct that is callable, and it probably won't work with any shared libraries on your system. Also it would be slightly slower, and C programmers tend to not be willing to make that tradeoff

D (and Pascal) implement it by adding and additional parameter to the function called the "static link". (The stack pointer is the "dynamic link".) The static link points to the stack frame of the function it is lexically nested inside. The compiler accesses the variables by offsets to the static link.

The best book I've found on this subject is Moral Mazes.

It's from about halfway through the process you describe. If you don't have time to read the whole thing, look for the section on "milking the plant"

Ooh, thanks for this tip. It looks great. Here's a summary: https://www.agsm.edu.au/bobm/teaching/BE/Cases_pdf/jackall-s...

The hardest language to learn is the second one.

You can learn the first one by rote memorization. But to continue down that path requires remembering the product of all language features x syntaxes.

> There are no markets without government intervention.

Of course there are. Black markets pop up everywhere to route around government intervention

Yes they do. Consider weed. It was well established before being legalized. Legalization brought higher taxes and interference. The black market continues as an alternative to the free one.

For obvious reasons a market for a product that is banned by the government is a poor example of a market that exists "without government intervention"