Clojure proposes that 'functional' and 'immutable' is 90% of the solution to writing highly parallel programs. Because Scala is imperative it doesn't suffer from the worst problems of non-composability of monads. Combining the type system of Scala with the functional purity of Clojure gives you Haskell, and this is where we find all the problems with the non-composability of monads.

Clojure proposes that non-composable 'records' are a problem with static type systems. In both Haskell, and I presume Scala it is possible to work around this using ugly type-system mechanics. This is really about the lack of Row-Polymorphic types in Scala and Haskell.

My main concern about Scala is that it is a Kitchen-Sink language that has resulted in a really-complex type system. I agree with you that it is not opinionated. But from the above it should be clear that Scala does not really suffer from the 'Monad Problem' like Haskell does, because Scala is imperative. It should also be clear that Rich's problems with compsable data could be solved in Scala by adding Row Polymorphism to the type system. My opinion of this is that Scala's type system is already too complex, and so adding further complexity if going to move Scala further from the language-sweet-spot.

@shelby3 An aside to the above, is that one thing I think a lot of languages get wrong is that the field names of a record are actually part of the type. This means that with first-class names (a name Kind alongside the type Kind) records are just Rows with 'named' fields. For example:
{"Age" Number, "Name" String}

This makes sense if you think that a struct is a type, yet has both field labels and types. Now as Rich says in his Clojure talk, just {Number, String} doesn't mean much, so perhaps it should not be allowed? So for rows we always require a name Kind for each field. Now we can see the Algebraic Effect types can be much more meaningful, for example:
procedure: () {"name" State String, "age" State Number | x} void

Here 'State' is a parametric Algebraic Effect, representing a mutable store which can store things with the type of the parameter. So 'procedure' can mutate 'name' and 'age' in an environment that contains other effects.
The State effect would define actions with polymorphic types like:
effect State a
    get: b:name -> {State a} a
    put: b:name -> a -> {State a} ()

where 'b:name" is a 'name' variable, which is like a type-variable except type variables range over the type kind, and name variables range over the name kind.

@keean I just discovered Vlang and I am liking what I see so far:
Even the main dev replied to my concern within a few minutes:
https://github.com/vlang/v/issues/43#issuecomment-692625107
They appear to be prolific devs. Interesting!
I am looking at their plans for concurrency:
https://github.com/vlang/v/issues/3814#issuecomment-692651004
https://github.com/vlang/v/issues/1868#issuecomment-692666717

@keean actually an intersection of interfaces as a bound on a type parameter is effectively row polymorphism wherein each field of a record is represented by a different interface. Thus Scala and Java support row polymorphism. Whereas structural subtyping is not row polymorphism.

@shelby3 how would I express that I want any record with a 'name' propery in Scala?

I already told you.

Scala has "structural types", which is the { val name: T } thing. The current implementation uses reflection on the JVM, giving rather poor performance.  I'm not sure about Scala 3.
In Scala 2, they're not quite first-class, either.
These are both okay:
def foo[T <: { def i: Int }](t: T) = t.i + t.i
def foo[T](t: T, extract: { def x(t: T): Int }) = extract.x(t)

But this is not:
def foo[T <: { def i: Int }](t: T, extract: { def(x: T): Int }) =
  extract.x(t) + t.i

I'm not sure of the capabilities along these lines in Scala 3, though.

Inserted this upthread...will delete this post after readers have been notified...
And followed-up again:

This was really focussed on a single, standalone join-function with no guarantees at the typelevel that it will behave as by relation algebra rules.

You’re misrepresenting what I wrote because ostensibly (?) you appear to think I am providing a concrete example as a goal of being literal, but I indicated I am just alluding to hints for the intuition of the abstract concept I am explaining. I stated essentially for your join or relational algebra or whatever you’re trying to type there. I was not nailing the concept down to only applying to typing a relational algebra or only applying to monads — those representative examples were just picked up on in our discussion as examples to refer to when talking about this abstract concept.

I believe that even without the guarantees that the function behaves exactly as an SQL join, having the typesystem support the structure is an enormous help to the developer that use such join function in their daily work.

Although I haven’t even tried to understand what you really want to accomplish with your join example because when I glanced, it appeared underspecified as to what you’re aiming for (but frankly I didn’t commit much thought to trying to figure out what you want), it appears you were trying to type something that the Scala typesystem may not be able to type without using some compile-time  type-level programming or perhaps dependent typing. In any case, the issue is that you are apparently demanding more control (i.e. structure aka order) from the type system and thus my abstract concept still applies.
Also I explicitly stated that in some cases the extra structure is justified. I clearly indicated that the circumstances vary and need to evaluated on a case-by-case basis. So I am not saying you definitively should not. I was discussing potential pitfalls.
When you become more knowledgeable about type theory then I expect you will appreciate more the tradeoffs involved. As type systems move away from the origin on the Lambda Cube, they lose principle types or soundness or degrees-of-freedom. There is no free lunch (which fundamentally at the generative essence is because of the physics I explained). And that is why your expectation below is afaics (nearly? 99.999%?) certain to be incorrect.

I don't even have to.

Note where Idris is relative to the said origin.
Hubris. Pride cometh before thy falleth.

There it is: the monadic laws, enforced by the typesystem. You said the motivation for monads is probably not the laws - I disagree

I’m sorry but I believe that you still do not understand at the holistic level of someone who has a broader basis of knowledge and experience in this subject matter.
You may benefit from the discussion I am having with Keean Schupke about this topic. @keean is the co-author of the comprehensive type theory papers Strongly typed heterogeneous collections and Haskell’s overlooked object system, c.f. also. The main author of that paper Oleg Kiselyov is well known as an accomplished type theory researcher. So the pedigree is present in the discussion at least.

And Idris is one of the few languages that tip the toe into the water and see what works and what doesn't. I share your sentiment that we are not at a point where we can do these things in production, but looking at what Idris can do today, I'm very sure this is just a matter of time.

There are some fundamental limitations of physics that can’t be overcome regardless of the movement of innovation, e.g. the Second Law of Thermodynamics. Unless you can paradigm-shift the problem to avoid the said inexorable limitation, then all that idealistic hope is vacuous and ill-advised. Repeating over and over again that which can’t succeed without actually addressing the fundamental limitation is a form of insanity. I am not discouraging you from trying, but please don’t declare I am incorrect before you prove it.  Because it is realized as a lesson in humility (←prediction of the future that will come to fruition).

META Rant: Ah the bliss of being young and green, c.f. also, also, also, also. I wish I could go back but with all the experience I already accumulated. IQ is not a substitute for experience and wisdom. I’ve even observed my younger-than-me 167 IQ friend commit numerous blunders (and recently died). Experience is often only gained by failing first.
Before our Western civilization became decadent, there used to be apprenticeship and respect for the experience of elders who had already mastered the skills. The joy was being able to pass this hard-earned knowledge down to the next batch who will carry the torch. With accepting regret I observe the many of the young Westerners today (and most programmers have less than 5 years experience) are Power Rangers who “think” they know better than the old, wrinked, atavistic fuglydudleys.
Sometimes the youth will invent something radically new which is a major breakthrough, but typically this is only accomplished by those among the youth who are scorned and ignored by their peers, e.g. Albert Einstein. If we’re young and as idealistic as our peers, we’re probably doomed to repeat (as a collective force and collectivized action) the analogous groupthink mayonnaise our grandparents did. That’s is one reason why at a very young age I decided to lean contrarian and rebellious against the majority (and also turn off the idiot box TV never to watch it again after circa 1987).

Inserted this upthread...will delete this post after readers have been notified...
And followed-up again:

This was really focussed on a single, standalone join-function with no guarantees at the typelevel that it will behave as by relation algebra rules.

You’re (unwittingly?) misrepresenting what I wrote because ostensibly (?) you appear to think I am providing a concrete example as a goal of being literal, but I indicated I am just alluding to hints for the intuition of the abstract concept I am explaining. I stated essentially for your join or relational algebra or whatever you’re trying to type there. I was not nailing the concept down to only applying to typing a relational algebra or only applying to monads — those representative examples were just picked up on in our discussion as examples to refer to when talking about this abstract concept.

I believe that even without the guarantees that the function behaves exactly as an SQL join, having the typesystem support the structure is an enormous help to the developer that use such join function in their daily work.

Although I haven’t even tried to understand what you really want to accomplish with your join example because when I glanced, it appeared underspecified as to what you’re aiming for (but frankly I didn’t commit much thought to trying to figure out what you want), it appears you were trying to type something that the Scala typesystem may not be able to type without using some compile-time  type-level programming or perhaps dependent typing. In any case, the issue is that you are apparently demanding more control (i.e. structure aka order) from the type system and thus my abstract concept still applies.
Also I explicitly stated that in some cases the extra structure is justified. I clearly indicated that the circumstances vary and need to evaluated on a case-by-case basis. So I am not saying you definitively should not. I was discussing potential pitfalls.
Also I should have made it more clear that the reason I responded initially to your post was to make a general, abstract point about the cons of static typing to counter-balance the pros. My goal and intent was not very specific to your example at all. Perhaps I threadjacked your subthread but I was essentially also replying to another post on this page that is cautioning not to ignore the cons of typing.
When you become more knowledgeable about type theory (if you aren’t already) then I expect you will appreciate more the tradeoffs involved. As type systems move away from the origin on the Lambda Cube, they lose principle types or soundness or degrees-of-freedom. There is no free lunch (which fundamentally at the generative essence is because of the physics I explained). And that is why your expectation below is afaics (nearly? 99.999%?) certain to be incorrect.

I don't even have to.

Note where Idris is relative to the said origin.
Hubris. Pride cometh before thy falleth.

There it is: the monadic laws, enforced by the typesystem. You said the motivation for monads is probably not the laws - I disagree

I’m sorry but I believe that you still do not understand at the holistic level of someone who has a broader basis of knowledge and experience in this subject matter.
You may benefit from the discussion I am having with Keean Schupke about this topic. @keean is the co-author of the comprehensive type theory papers Strongly typed heterogeneous collections and Haskell’s overlooked object system, c.f. also. The main author of those papers Oleg Kiselyov is well known as an accomplished type theory researcher. So the pedigree is present in the discussion at least.

And Idris is one of the few languages that tip the toe into the water and see what works and what doesn't. I share your sentiment that we are not at a point where we can do these things in production, but looking at what Idris can do today, I'm very sure this is just a matter of time.

There are some fundamental limitations of physics that can’t be overcome regardless of the movement of innovation, e.g. the Second Law of Thermodynamics. Unless you can paradigm-shift the problem to avoid the said inexorable limitation, then all that idealistic hope is vacuous and ill-advised. Repeating over and over again that which can’t succeed without actually addressing the fundamental limitation is a form of insanity. I am not discouraging you from trying, but please don’t declare I am incorrect before you prove it.  Because it is realized as a lesson in humility (←prediction of the future that will come to fruition).
I don’t disrespect you. I respect you for engaging in the discussion in a calm and respectful tone. And I respect you for questioning me and being skeptical. I hope you continue with your tenacity in all endeavors. And I hope I can count you as friend someday.

META Rant: (not implying this applies to you) Ah the bliss of being woke, young and green. Shockingly it’s only 9,000 …ahem “car accidents,” c.f. 1, 2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 93, 94, 95, 96, 96, 97, 98, 99, 100, 102, 103, … nth. I wish I could go back but with all the experience I already accumulated. IQ is not a substitute for experience and wisdom. I’ve even observed my younger-than-me 167 IQ friend commit numerous (what appeared to me at least to be) blunders (and he recently died). Experience is often only gained by failing first.
Before our Western civilization became decadent ←important link, there used to be apprenticeship and respect for the experience of elders who had already mastered the skills. The joy was being able to pass this hard-earned knowledge down to the next batch who will carry the torch. With accepting regret I observe the many of the young Westerners today (and most programmers have less than 5 years experience) are Power Rangers who “think” they know better than the old, wrinked, atavistic fuglydudleys.
Sometimes the youth will invent something radically new which is a major breakthrough, but typically this is only accomplished by those among the youth who are scorned and ignored by their peers, e.g. Albert Einstein. If we’re young and as idealistic as our peers, we’re probably doomed to repeat (as a collective force and collectivized action) the analogous groupthink mayonnaise our grandparents did. That’s is one reason why at a very young age I decided to lean contrarian and rebellious against the majority (and also turn off the idiot box TV never to watch it again after circa 1987).

Inserted this upthread...will delete this post after readers have been notified... (hopefully almost done with my interaction on Scala forums as I detect the community is very unrealistic)
And followed-up again:

I was pretty much saying "hey, it would be nice if we can built safety belts for cars" and you come in and say "but, you know, it's physically not possible to build safety belts that save your life in any scenario!". ;) You are right, but it doesn't really add anything to this specific post!

I was not attacking you. I was adding commentary about typing. I was trying to help readers understand that there are cons to typing as well as pros that have to weighed.

You are biased. Biased in the sense that you have worked too much with languages of compariable simple typesystems such as Haskell or Scala. Oleg tries to make things work in the world of limited productive languages such as Haskell in Scala. I'm not sure how much experience he has with first class dependently typed languages.

What have we written that is incorrectly biased?

And while you are right that Gödel and Turing stop us from doing certain things, I'm starting to wonder if you could actually come up with a practical problem that cannot be modeled with Idris in a typesafe and composable way at this point in time. (given that it is conceptually composable, so don't start with Monads again)

I never wrote it would be impossible to code in such complexly typed models did I? What did I write? I was writing about composition at application-scale and the impacts on productivity, efficiency, code readability,  and level of tsuris, etc..
Sure we could in theory perhaps have excavated the Panama canal with spoons if we were willing to sacrifice enough lives, but that wouldn’t be a productive activity. And you may[very likely will] soon discover how difficult it is to eat when we-as-a-collective-society ignore economics. And the eating part is a looming, realistic threat, not just some kooky metaphorical idiom.
Also Idris falls in the category of total functional languages with a totality checker meaning they prove that programs halt and thus not Turing-complete.
This mention of economics reminds me that I am wasting time here. Gotta go. I tried to help. Seems it wasn’t appreciated. Adios.

Inserted this upthread...will delete this post after readers have been notified... (hopefully almost done with my interaction on Scala forums as I detect the community is very unrealistic)
And wrote:

I am dreaming of a world where everything is typed

This is a dangerous way to think IMO.
Typing, like every other tool we use, come at a cost. It is not a silver bullet that magically fixes everything. I don't like it if people fetishise it.
Use types by all means. But at least try to understand the cons, not just the pros.

I tried to explain what I think can be some of the cons of overly convoluted static typing, but seems that may an anathema to some of Scala-nians around here?

I followed-up on the prior one above:

I agree with all that you wrote except the last sentence appears to be incompatible with your thesis?

I'm really sorry I can't reply to all the points you're making due to sheer lack of time, but I'll try to defend my thesis a little :)

Thanks for the reply. I will understand if you’re too preoccupied to reply again.

I don't think working on tooling and embracing diversity of point of views is incompatible : the scala-center is driving an effort to allow for tooling to evolve whilst retaining unopinionated-ness : the build server protocol (an extension of the LSP) allows IDEs/editors to communicate with build tools without awareness of each-other's specifics. This means that people who want to use SBT and vscode can, whilst people who like to use vim with mill can. This also means that you can literally come-up with your own build tool at reduced cost and benefit from existing editor support. Seed is a great example of this.
I love the fact that the Scala ecosystem is evolving in this direction, it fosters healthy competition which generally improves everything for everyone.
Also, tools like ammonite are insanely helpful to a very large subset of the community, and I don't think it forces any debatable decision down the throat of its users.

I read today about the massive, intensive effort. I hope they can achieve some of their goals and I wish them good luck with it.
Afaics that desire to accommodate everything prioritizes experimentation over focused, tightly-integrated execution — which is what I mean by relegated to being a research language and ecosystem.
Afaics, it’s inclusive in a small pond. The chaos of 31 flavors of multiplexing very likely means continued low adoption. Sorry to say but in my opinion and analysis (and I am analyzing this as a prospective adoptee of Scala 3), most of those who need production quality will run away from the chaos and confusion unless there’s no better tool and ecosystem for their use case, which has been the headline news story for Scala ever since I began tracking it in 2009 (although I don’t know if I should entirely believe the negative hype).

Scala is a research tool for a diverse community.

You're not wrong, but that statement is quite limiting : Scala is also an industrial language used by a number of big companies that collectively account for a fair portion of the world's internet traffic.
Just to name a few : * Netflix * Twitter * Disney Streaming (which I work for)
You can say what you want, but despite not being "mainstream", Scala is a successful industrial language.

Yeah that is why I have to be somewhat skeptical about headline news because the serious money behind the curtain may not be running around boasting about how much they spend on Scala development.
Nevertheless I ponder if this is primarily because the alternatives for statically typed concurrency development on servers have sucked. Go has a better runtime than the JVM (i.e. stackful green threads) but no statically typed genericity. Python can’t even compete in concurrency because of the global interpreter lock. And so what happens to Scala if someone marries Go’s runtime to Scala’s type system but it’s not Scala? Would it cannabalize Scala’s developers if Scala does not have as competitive of a runtime? or would it be ignored because it’s not exactly Scala nor exactly Go? Seems I am not the only one who is not enamored with the JVM?
What motivates your company to use Scala instead of other alternatives and endure all the breakage and chaos of this ecosystem?

I haven't been comfortable with low-level languages for a while (nor front-end for that matter), and I love that Scala brings me access to other runtimes (scala-native is reconciling me with pointers and scala-js is reconciling me with front-end). If there were more runtimes supported, I'd be ecstatic.

I am contributing design suggestions to Vlang as of yesterday and pondering if this might be a better replacement for Scala Native. Vlang has a syntax and planned feature set very similar to Go but aims to fix the mistakes Go made and Vlang compiles to C. It’s still early days though.

I however disagree with how you imply that top-down decisions should be made at the language level to support this particular use-case. That will always be unpopular discourse, as people depend on the same language for usecases you're not talking about. It's very much a case of "build it first, and people will come"

I wasn’t proposing any top-level decision. I was just talking and seeing if anybody wanted to discuss. I am not expecting anything to come from other Scala devs to make any of my suggestions or ideas a reality. If I decide something is worth doing and I am capable of doing it, then I will start coding. I just haven’t decided yet what is my next move.

You can have the most interesting idea in the world but until you've actually prototyped it and established feasibility, ideas are utterly worthless.

“Talk is cheap, show me the code” — Linus Torvalds

Scala 3 - A community powered release

I haven’t decided yet whether I am looking forward to the Scala 3 release or dreading the slim possibility I might be lured from my several years soberness back into drinking the Koolaid and choking on hairballs?

I wrote:

Rather than trying to have a language that answer to all calls, a sustainable and pragmatic approach is to be adaptable, and embrace language and technology that resolve our needs and problems, because we don't often get to choose the language of our choice in the real world to solve our problems effectively. What is good for us may not always be good for others as people make different choices when it comes to language and ecosystem.

The implication is that if a programming language is not both popular enough as well as suited to needs (not just one of the two), then likely we will not be allowed to choose it when working in teams at a company. And if a programming language is not focused and opinionated, then it is unlikely to become popular.

I followed-up for the last time:

I don't think "total functional languages" is a common term. I know functional programming and I know totality, but I google this term and what comes up are programming languages that are constrained to only allow to write total programs.
So I have to interpret you. And my interpretation is, that you actually have misunderstood this property of Idris. Idris is not a language that forces you to write total programs. Not at all. The language allows you to write turing complete programs. What it does is, it checks if functions are total and restricts the usage of functions that are not proven to be total to be used for describing the shape of types.
So, you either got it wrong or you meant something else but used undefined, vague terms. Just make your life easier by not doing that, and we can save 90% of the typing. :)
Still, thank you for the discussion!

Thank you also for the discussion.
Please do not extrapolate my intent from what I did not write to what fits a strawman argument. I did not write that Idris only has the capability for total orders and no other paradigms.
Please do not confuse the bark on the trees from the salient bigger picture of looking over the forest to remember what this discussion was about from my perspective — the fragility of overly convoluted typing which is a feature of Idris regardless. Idris as I wrote from the first comment I made about it is a dependently typed language, meaning that values can be modeled as types.
I have not written that it will never be useful. I even mentioned some cases where I could imagine it will be useful and there may be more.
I am all for exploring type theory. Again my goal here was to discuss some of the tradeoffs at the outer limits of the capabilities of typing.

I proposed Pony-esque recover blocks for constructing immutables? for Vlang and perhaps also for any programming language I may create.
Also I want to correct my error, if I have ever (especially recently) implied or stated that Scala enforces immutability. Scala’s val only prevents reassignment, and does not make the referent object immutable. This is an egregious flaw, but it’s understandable because a programming language will need at least Pony’s recover block feature in order to initialize immutables. C.f. the linked proposal for more details.

The big break in computer languages

I prefer go, but Nim is pretty neat.

Huh. And now it turns out that a guy who tried writing a Unix kernel in Rust bailed out to Nim.
This surprises me. I had bought into the pro-Rust argument that, once it matured, would be a good match for kernel development on theoretical grounds related to the tradeoff between the benefits of type safety versus the additional friction costs of Rust. Now someone actually working at that coal face says “Nope.”
More detail here.
I suppose it’s possible that sticking to Rust would have been a better choice and that the guy is just incompetent, but his discussion of the issues seems pretty thoughtful.

@keean wrote

My main concern about Scala is that it is a Kitchen-Sink language that has resulted in a really-complex type system. I agree with you that it is not opinionated. But from the above it should be clear that Scala does not really suffer from the 'Monad Problem' like Haskell does, because Scala is imperative.

Agreed and Scala’s creator Martin Odersky admits in his recent talk about Scala 3 that his goal has been to create a unification of disparate (and you and I assert ill-fit, although @Ichoran disagrees) programming paradigms.

Odersky does mention some of the downsides which Scala 3 attempts to fix, but he doesn’t address the essence of two many paradigms in one PL:

Odersky admits when he discusses the new exports capability that inheritance is bad and should be avoided. So why keep it in the PL? Probably because Scala has it genesis and thus DNA as a research language.
Note I will come back to the remainder of what you wrote in that post, but first I will respond to the post you made before that as follows. I quote the above here because I want to point out that I think Scala sacrifices the opportunity to be sufficiently opinionated enough to have an optimum balance of limited but sufficiently powerful abstractions for a simple language per your point quoted below.
@keean wrote:

As you know my interests are more in developing a small/simple language with powerful abstraction capabilities.

Agreed. Yet it seems we differ (in the way we conceptualize) on what the correct abstractions should be in order to make a simple and thus popular language.

Starting with Stepanov’s ideas from "Elements" as a core idea. Something that lets you manipulate bits and bytes (write hardware drivers for example), yet allows safe coding at a higher level.

Powerful, mathematical or algebraically generative essence abstractions can be too low-level and too literal. For example my recent epiphany obviating and swiping away Rust’s literal and low-level encoding of total order on exclusive writability, with a simpler abstraction by cleverly leveraging that types exist.
A tradeoff has to be made because there’s no free lunch. We can choose abstractions which serve the 80/20 needs and arrive at an elegant, popular and simple PL, or we can attempt to be as literal and exhaustive as you ostensibly want to be and end up with another STL mess. Perfection can be the enemy of good.
I’m skeptical about whether it’s possible to design a PL that is optimal for the extremes of both HLL and LLL programming. Rust, C++ and other PLs have attempted to combine for example HLL generics, closures, etc with LLL optimizations and the result has been painful complexity, unsoundness, and extreme difficulty in staying within the intended paradigm without punting to for example inefficient and leaky ARC. In general for example low-level specializations seems to multifurcate generics into a noncomposable mess analogous to What Color Is Your Function?
However I’m also contemplating that Low Level Language Programming Is Considered Harmful and Antithetical To Optimization at least due to radical paradigm shifts on the long-term trend.
Something like V(lang) or Go(lang) is all I should need for non-extreme (i.e. not as performance and space optimized as C++ or Rust) LLL programming in most cases that don’t require the optimization of assembly language or extreme control over avoiding redundant copying such optimization of result value temporaries, as can be accomplished with C++ move semantics and perhaps also in Rust? V even allows pointer arithmetic in unsafe{} blocks, although that is not really even desirable for performance not mention being unsafe and Go doesn’t make that mistake. Note I explained in the aforelinked that my ALP bump pointer heap idea combined escape analysis may in the non-extreme use case, ameliorate the necessity of further  optimization of result value temporaries. Remember the power-law distribution aka Pareto principle aka the 80/20 rule that performance critical paths of the code are likely to be a very small percentage of the code case of an application.
I might be more enthusiastic about Rust for LLL coding if they hadn’t tried to compete with C++ and instead just made a better C, e.g. the complexity around closures, c.f. also and also. But Rusts wants to be a HLL tool also, which thus afaics makes it extremely complex as is also the case C++ with the complexity lurking in the apparently unsound type system.
Eric Raymond wrote an unflattering opinion about Stepanov’s STL and C++’s overall complexity:

[…] After which I swore a mighty oath never to go near C++ again.
My problem with the language, starkly revealed by that adventure, is that it piles complexity on complexity upon chrome upon gingerbread in an attempt to address problems that cannot actually be solved because the foundational abstractions are leaky. It’s all very well to say “well, don’t do that” about things like bare pointers, and for small-scale single-developer projects (like my eqn upgrade) it is realistic to expect the discipline can be enforced.
Not so on projects with larger scale or multiple devs at varying skill levels (the case I normally deal with). With probability asymptotically approaching one over time and increasing LOC, someone is inadvertently going to poke through one of the leaks. At which point you have a bug which, because of over-layers of gnarly complexity such as STL, is much more difficult to characterize and fix than the equivalent defect in C. My Battle For Wesnoth experience rubbed my nose in this problem pretty hard.
What works for a Steve Heller (my old friend and C++ advocate) doesn’t scale up when I’m dealing with multiple non-Steve-Hellers and might end up having to clean up their mess. So I just don’t go there any more. Not worth the aggravation. C is flawed, but it does have one immensely valuable property that C++ didn’t keep – if you can mentally model the hardware it’s running on, you can easily see all the way down. If C++ had actually eliminated C’s flaws (that it, been type-safe and memory-safe) giving away that transparency might be a trade worth making. As it is, nope.

Also Eric blogged C++ Considered Harmful:

C++ is an overcomplexity generator. It was designed to solve what
turned out to be the wrong problems; as a result, it lives in an
unhappy valley between two utility peaks in language-design space,
with neither the austere elegance of C nor the expressiveness and
capability of modern interpreted languages. The layers, patches, and
added features designed to lift it out of that valley have failed to
do so, resulting in a language that is bloated, obfuscated, unwieldy,
rigid, and brittle. Programs written in C++ tend to inherit all
these qualities.

One of the commentators wrote:

The thing that really convinced me that C++ was a language whose time had passed was reading Scott Meyers’ books Effective C++, More Effective C++ and Effective STL, which could be seen as a long list of gotchas and workarounds that must be borne in mind when writing C++. Any language that required you to deal with this nonsense on a daily basis was clearly wasting its users’ time.

So I suspect Linus Torvalds is correct that C will remain the PL for operating systems if one has to routinely punt to unsafe in Rust and because I argued to @Ichoran upthread that even just one unsafe instance in your program incurs the potential liability of vacating all the guarantees of the type system (in various insidious ways).

My own direction seems currently based around Algebraic Effects, A row polymorphic type system with HTK based on Prolog, Typeclasses, Actors (single threaded / arena things), Clojure's Epochal timeline, and Pythons layout is syntax.

I appreciate your insight explaining that row polymorphism is a response to one of Rich Hickey’s major criticisms of typing.
Afaics, Clojure's Epochal concept is essentially just immutability and making immutability more efficient with persistent data structures that only duplicate changed data. Persistent data structures share (between threads) those items in the data structure which haven’t be modified. I suggested that each thread should inform other threads sharing the same data when a change is made to a private copy of the data. I wrote:

One possible model for mutating shared immutable data is for the exclusive owner to create a new mutated, immutable copy (perhaps via an efficient data structure that only copies the changed part which afaik is what Clojure employs), then send a message to threads to tell them to update the copy of the immutable data they are referencing.

I have yet to read a coherent argument in favor in the benefit vs. drawbacks analysis of Algebraic Effects. I’m not claiming there isn’t one? You’re prior attempts at explanation apparently hasn’t stuck yet in my mind.

I hope to combine these features in a synergistic way (the whole is greater than the sum of the parts) embracing Pythons "one way to do things". Something like a combination of Rust (using the Reference Counting memory model) at the low level and TypeScript (with HKT and Typeclasses) at the high level. However much simpler versions of both of these. So no explicit lifetimes in the low level (RC memory model allows implicit lifetimes to statically optimise without creating red/blue function bifurcation for generics between static and dynamic memory management), and only Typeclasses/Algebraic effects at the high level (so no classes/interfaces).

We discussed that upthread with @Ichoran.

What needs more work is the Actor/Module system, can that be folded into the Typeclasses/Algebraic effects?

I’m still progressing on my ALP idea, but it’s not yet a holistically, defensible design.

One of the problems I want to solve is the library problem with typed languages (something the Clojure talk mentions) where you may have a library function like "sort" that effectively calls back to your own code for "compare", the generics should be sufficient that you can change the type of compare without having to change any of the library code, also there should only be one implementation of compare and sort, not different ones for pure/impure compare, or different ones for static/dynamic memory management etc.

Agreed. And we’ve devised some ways to tackle the modularity #39  issue with typeclasses in light of Robert Harper’s criticism, “…the integers can be ordered in precisely one way (the usual ordering), but obviously there are many orderings (say, by divisibility) of interest…” Although I surmise you’re somewhat unsatisfied with violations of the total ordering required to insure the abstract algebra.
Clojure’s, Haskell’s and Go’s mistake of structural instead of nominal matching of functions to (typeclass) interfaces amplifies Rich Hickey’s criticism of an explosion of interference and boilerplate with types.

If you can have one optimal implementation for a kind of sort (say quicksort) then Stepanov's idea of an online algorithm repository can become a reality. The type signature would not have to change for different implementations, and so the language standard library becomes a collection of algorithms which can work on any data-structures (you just have to provide the needed typeclasses).
The goal is only one implementation of quicksort is needed in the whole world (of this language). This would be managed by a Deno like import manager. The language repo itself would provide the 'approved' algorithms.

Perfection can be the enemy of good.

Somehow we also need to encourage libraries to only contain algorithms and typeclass definitions, so I am wondering if we can have a syntactic limitation that disallows type definitions in libraries. I'm thinking about the Clojure presentation that it's what you choose to leave out of a language that is important. They probably need internal types for book-keeping, so maybe just ban concrete types in the interface/module specification?

Philosophically I agree. I will need to think about implications of this specific design suggestion.

I responded on the thread Dotty becomes Scala 3:

Here we go! I’m really hoping this sparks some renewed interest in scala. Scala 3 is exciting, but it really needs adoption. I’ve been using scala for a long time, but it’s really tough to find clients (other than the “we use scala 2.11 with Spark).
There’s a lot more spread now - it seems Rust, Go, Dart, etc are all getting more hype, not to mention all the JavaScript variants/spin-offs.
I think a real “this is how you use <cool framework/paradigm> in a fast/productive way with scala3/scalajs” would really help - or similar w/ scala native

It going to be hard competing with languages like Kotlin. What i personally like about with Scala though is the attention to get it right from a theoretical perspective. Perhaps Scala won't ever be one of the bigger languages but perhaps that won't matter as long as it has enough traction to stay in its current place. Maybe in the future when webassembly becomes huge then platforms wont matter as much and then it will be even easier to mix and match languages. Then perhaps people can move more freely between languages and experiment.

As you allude to “right from a theoretical perspective,” Scala enables abstractions which aren’t possible and/or not nearly as elegantly expressed in Kotlin due to for example the lack of native higher-kinded type (HKT), typeclasses, structural intersection/union type lattice, operator overloading, path dependent types and robust pattern matching in Kotlin (and probably many other nuances such a value types which are ostensibly useful for example for efficiently emulating new type system features). I realize there’s the Arrow_kt and KindedJ emulation of HKT, but I presume this at least forsakes some facets of elegant expression. Personally coming from the stance that class inheritance (aka subclassing) is an antipattern compared to typeclasses (which even Scala’s creator Odersky admits) so in comparison Kotlin’s focus on OOP and better integration with precipitously declining JVM/Java platform is not the direction I want to go in order to be ‘future proof.’ Afaics the JVM is inferior in terms of performance scaling for backend services compared to native green thread optimized platforms such as Go(lang). This is why I am contemplating a Go(lang) target for Scala from a subset of Scala which discards the unwanted subclassing. Focus on strengths. Be an opinionated language, not just a research language. Click the following link to dive into the details of my thoughts on the linked posts and the comment posts which follow the linked one:
https://github.com/keean/zenscript/issues/49#issuecomment-691668695
In short Scala should let Kotlin have the JVM and Android ecosystems and not focus there although maintain compatibility. And focus more on its strengths for backend services wherein the advanced type theory features are more compelling. And focus on a runtime that will be superior to the JVM and which is can scale to massively multicore which has arrived. The JVM will be more difficult to scale to massively multicore. Even Go is not ideally designed to address the fact that immutability and no global AMM will afaics be the only reason way to scale. Both Kotlin and Scala are inching towards native support, so do we want to end up with the less elegant but more pragmatic Kotlin as our future language as the transition away from the eventually deprecated JVM emerges into view? I also wonder if by pruning Scala’s features of antipattern programming paradigms, if that might unfurl opportunities to increase the compiler’s performance? (Note I typically tend to think about 5 to 10 years ahead and so I often look like a foolish person until nearly every time I am proven correct in the end, as has happened so many times in my life)
Excuse me in advance if my comments are myopic, which is quite plausible because I haven’t been active developer for at least the past 5 years (and not really intensely for more than a decade). I have been following Scala on and off at a distance since ~2009. I am excited about Scala 3 but still on the fence because of the legacy baggage of subclassing and the JVM diluting focus. I realize such a sentiment may be unpopular. Please do not downvote me because you disagree. Disagreement should be expressed by not upvoting and responses. Downvoting should be reserved for flagging trolling. Reddit(ard) needs a separate metric for expressing opinion because downvoting impacts visibility and ostensibly even shadow banning.

I will quote from Kotlin vs Scala: Which Problems Do They Solve? for readers who may not be familiar with the comparison of Kotlin vs. Scala:

Scala has been designed in the Academia, Kotlin in a leading software company. The background in which they are born explain most of their differences. Scala has been born to try some cool ideas on functional programming and mixing different paradigm. Kotlin is about solving practical problems. Kotlin designers cared about compilation times and great tool support, because those things matter to programmers, even if they do not sound exciting for other language designers.

Very interesting:
Notes on smaller Rust
Revisiting a smaller Rust
The corresponding blog is here.

Attempting to paradigm-shift our discussion about resource cleanup and incidentally RAII. In a purposely (re-)designed operating system (OS) I can’t think of any reason for non-memory “resource starvation” in terms of forgetting to release the handle to the resource? The entire filesystem could be virtual memory mapped or at least there’s a nearly unbounded number of 64-bit file handles. TCP/IP streams should be limited only by data structures allocated in memory so any resource limitation is synonymous with memory resource starvation.
There can be resource starvation for example reading too infrequently from Internet stream buffers thus causing the TCP/IP connection to go stale or timeout (arises as we had discussed in years past, for example in the tradeoff between throughput versus latency in concurrency), or forgetting to release exclusive access to a shared resource such as exclusive write. But the first has nothing to do with forgetting to release access to the resource and the second exists with the broader scope problem of deadlocks and livelocks. For example perhaps the only way to guarantee there will never be deadlocks and livelocks over file write access is give exclusive write access only to an owner application and allow other readers unfettered access. Batch file writes could be employed so that readers never access partially written inconsistent data (yet readers would never wait they would just read the prior version of the data while the batch is not yet completed) , although in theory this could create an obscure livelock wherein the reader needs the batch update to interact (even indirectly) with a dependency for the writer’s completion of the batch write.
One could imagine resource starvation due to forgetting to release for example the camera of the mobile device, yet presumably the OS can give the user a manual override for such a buggy application given it is a resource the user interacts directly with.
Thus to the extent that AMM (e.g. via a tracing GC) is acceptable for unused memory resource collection then it should be acceptable for access to all types of resources?
Not closing a TCP/IP stream may keep resources on the other side of the connection tied up until the connection times out, although typically one should either being using long-lived connections or connections set to close automatically after the response. And this shouldn’t be conflated with release of resource handle as we did upthread. I would return to my original upthread point that ARC-based RAII will not insure timely release due to the potential for insidious cyclical or dead references. Thus the programmer won’t be able to rely on it without perusing the semantics of the source code which is thus perhaps not arguably better than explicitly coding the close of the connection.
The resource cleanup drama was a red-herring. Certainly not a valid justification for using Rust.

I wrote:

I don’t want the tsuris of Rust’s lifetimes which includes even inability to accommodate unfettered cyclic references in addition to numerous other points that have been, including that we have to punt to ARC in Rust when our dynamic needs outstrip what static lifetimes can model and @keean claiming out he can’t implement certain algorithms without unsafe code. @keean would slices not help?

In addition to Rust lifetimes being unable to model some semantics correctly, Rust exclusive write lifetimes are useless for preventing unintended concurrent access to parallelism that is sorted by contextual values at runtime.
Imagine I have a blockchain application that will sort transactions by the UTXO records they will invalidate or write to. We don’t want more than one thread accessing the same records concurrently causing a race condition bug. So we queue conflicting transactions. Rust has no means of modeling this statically at compile-time. The thread that is a queue needs exclusive write access to the records it will operate on, but this guarantee only semantically by said queuing based on contextual values at runtime.
Ditto a smart contract for an exchange that has to sort bids and asks by trading pairs so that conflicting transactions for each trading pair are queued. The only other way to speed this up would be pipelining of the said sequential queue.

I can feel it coming in chesterfield tomorrow sparked a fire in my soul bless your heart attack die rich

@shelby3 Just want to remind you to keep to programming language discussions here to keep the noise down.
Regarding syntax, one option is to regard the language abstract syntax tree as the fixed-point, which you might store as JSON or XML or some such thing that can store tree formatted data. Then users can choose to render the tree according to house style rules when they view things.
I think this is a good solution to the religious wars that start about the exact coding style that should be checked in repositories. Should there be one space or two, tabs or spaces etc...
Store a machine readable AST directly, and leave it to the IDE to render. In this way each developer can see all the code in the repository in their preferred style.

@keean - For reference, I think the AST-is-ground-truth idea (not "essentially" proposed elsewhere) is really interesting.  I don't know if it would be practical, but I think it's an interesting idea especially for Scala since it already has an internal AST that is stored (TASTY).  Could we form an adequate bijection between TASTY and editable forms?  Probably not.  But that doesn't sink the idea--you can then ask whether you could have a rich text AST that could be reduced to actual TASTY, and the rich text AST would be ground truth.
Would that work?  Dunno.  And it wouldn't solve the problem of needing to read code pasted into discord and github and stuff.  But it's an interesting intellectual contribution towards solving the how-do-you-edit-your-favorite-flavor-and-let-others-do-likewise (which, for the record, I never opposed...I just didn't think it solved the whole problem, so the other potential issues with language dialects could not be dismissed wholesale without addressing them).  The reason it's interesting, unlike the others, is that writing code is really just our way to express that we want a particular AST.  Having the AST itself be the common form (even if not really readable on its own) is therefore a particularly pure way to handle dialects: in principle, one could consider any dialect for which there is a bijection with the AST.
(The main issue I can foresee is that it would be difficult to allow ad-hoc indentation and spacing, like vertical alignment of common elements to reduce the chance of error.  A rich text AST might be able to support this if all dialects could permit the same thing.  But without this, historical code bases would be grandfathered in at best: you could have an surjection from them to the rich text AST, but you couldn't get back.)
Anyway, it's an interesting idea that I hadn't heard before that's a step above the usual "run the code formatter" / "write a syntax translator" idea.

@Ichoran would you elaborate on @morgen-peschke’s claims that there are subjective decisions to make about where the place braces in Scala where apparently they are option and don’t change the semantics at all but change the readers interpretation of code? That is bizarre and seems like bad programming language design?

The reason it's interesting, unlike the others, is that writing code is really just our way to express that we want a particular AST.

Apparently not according to  @morgen-peschke’s claims. Apparently there are cases where the mere presence of braces in Scala even where their presence makes no difference to the AST, has some bearing on the reader’s interpretation, at least according to him.
So don’t go trying to act so hoity-toity as if you had some highly intellectual reasoning in mind that had escaped anyone else here.

@Ichoran @keean
I don’t mind if @keean deletes all our recent exchange.  I also fault @keean for believing all the technocracy lies about COVID and what not, but @keean gets a pass because he is open to debate. And eventually @keean and I will have that debate. He may find some sophistry to continue on believing in his enslavement and that is find maybe it is his destiny. But at least @keean will engage me respectfully when I am ready to do so. Whereas @Ichoran was cursed with a very high IQ so thus thinks he knows more than the person he is engaging with. @Ichoran would not respectfully engage in a challenge to his belief system. It is his UNDESERVED arrogance that is the huge turnoff. But he will be judged and he will reap what he has sown. That’s not my job to mete out his punishment. That is above my pay grade. He will not escape the truth nor punishment for the horror he has arrogantly help perpetrate and perpetuate on humanity.
When he says lies, I probably know what he is referring to. I have been to that highly technical scammer website that purports to be refute all the arguments against the scam.

@Ichoran @keean
Here we go again Scala doing their usual unnecessary complexity routine.
For example, but not adopting the 3 spaces enforced rule, and instead trying to be too cute, you all are creating problems and complexity:
https://contributors.scala-lang.org/t/feedback-sought-optional-braces/4702/34?u=shelby3
The above is presumably the attempt to automatically detect unintentional single-spaces. Very, very bad. What is Odersky doing?
Stop adding unnecessary complexity.

@shelby3 - I will discuss political philosophy and historical and current world events in an appropriate venue.  This is not such a venue, even if it is less stringently not such a venue than the Scala forums.  Pick an appropriate one and I will engage for an amount of time that I can afford (probably ~2000 words max).  Time and place permitting, I'm always open to discussing important issues.

@Ichoran, okay fine. Please realize I am not a total dunce. My mother has a rigorously tested 137 IQ and my father has a significantly higher IQ, so I am at least not retarded in any case.
https://contributors.scala-lang.org/t/new-braceless-syntax-needs-more-thought-before-being-adopted/5722

@Ichoran @keean:
I added this just for you guys:
https://contributors.scala-lang.org/t/new-braceless-syntax-needs-more-thought-before-being-adopted/5722/2

Does anyone remember when they could hold the entire K&R C book in their head.

@shelby3 Just want to remind you to keep to programming language discussions here to keep the noise down.
Regarding syntax, one option is to regard the language abstract syntax tree as the fixed-point, which you might store as JSON or XML or some such thing that can store tree formatted data. Then users can choose to render the tree according to house style rules when they view things.
I think this is a good solution to the religious wars that start about the exact coding style that should be checked in repositories. Should there be one space or two, tabs or spaces etc...
Store a machine readable AST directly, and leave it to the IDE to render. In this way each developer can see all the code in the repository in their preferred style.

Impossible because Scala screwed itself early on:
https://contributors.scala-lang.org/t/make-fewerbraces-available-outside-snapshot-releases/5024/130

So this is what the world has come do. We really do need to enslave all of you. Just continue your support the technocracy guys, it’s your destiny.  Glad I realized it sooner than later.
https://contributors.scala-lang.org/t/which-features-of-scalas-use-of-braces-making-bijection-translation-from-braceless-block-implausible/5723

Don’t expect any communication from me for a couple of days, as I have my head in the programming sand attempting to accomplish something Herculean. (Some people pissed me off and that is a big mistake when I am healthy)
I now have diarrhea with the Ivermectin but I interpret this as a good sign. My health seems to be improving. My concentration is unreal. I am coding as I did in the past. Didn’t sleep for 24 hours. No problems so far.
👍👍👍👍👍👍👍👍

Have a moment to jot down what has transpired which I will do now, because that ostensibly (possibly radical) leftist @morgen-peschke ostensibly mistakenly thought that—by violating the Scala Contributors discussion group’s Code of Conduct, by linking to off-topic discussion here in this thread—he would malign my character in the eyes of others. I guess he didn’t realize that I am delighted if others know that I am angry at @Ichoran for his complicity in the COVID scam, which has been a massive crime against humanity. Why would I be ashamed of protecting humanity against criminal syndicates and their sycophants? But I wasn’t going to spam the Scala Contributors group with my longstanding issue with @Ichoran. So that juvenile twat did it for me, lol. Th mods (presumably @sjrd who is also the lead programmer for Scala.js) hid all my responses to that freakazoid’s Code of Conduct violating activity but not the actual CoC violations of my protagonist (c.f. link above). So @sjrd who is ostensibly the sole mod for Scala Contributors (ya know the Scala is community is really tiny with only 0.7% market share up 0.2% recently due to Scala 3 compared to 1.4% for Go, 1.6% for Kotlin, 2.4% for TypeScript, 9% for JavasScript, 18% for Java and 28% for Python) might be breaking the law (will need to ask my attorney to look at this) by violating contractual language resulting in intentionally schemed libel (private companies have a lot of leeway but they’re not entirely above the law although I’m not an attorney). The legal stuff is not my purview, but I share the need for a programming language with the community-at-large (not including the leftists cretins will never have a safe haven for their disruptive activities in any project I manage so they better not even try) and the technology is my forte, so…
This was after I had been graciously receptive to @morgen-peschke’s militaristic attitude against the new Scala feature to offer an optional braceless syntax. I was attempting to have a reasonable discussion with him about his claims that being autistic means he can’t read code without braces. I noted he could continue to code in braced style as Scala will offer both. I posited that maybe we could encourage the Scala team to offer libraries in both braced and braceless. I also raised the possibility of an automatic translation between the two styles, as well I suggested multiple colored vertical traces (to help distinguish them rapidly) in the IDE. I even pushed back against @Ichoran’s FUD about small snippets of braceless shared in Discord being hard-to-read as even he agrees small snippets are often easier to read in the braceless style. But no, @morgen-peschke would have none of my attempts to find reasonable compromise (and even I am not the one forcing the new feature down his throat as the Scala BDFL Odersky is pushing it through).  I told him that many autistics have an inability to perceive reality correctly and that he was exaggerating.  Note @sjrd hid that very important aforelinked post (which aims to head off bugs and unnecessary complexity Odersky is foolishly adding to the new feature), so I have screen captured it as follows:

The mod (presumably @sjrd) deleted my post to justify the claims I started making about why Scala needs a better native compile target. Note the mod also closed that thread to prevent the points from being made. Clearly they’re trying to hide Scala's weaknesses from the users, as they must realize Scala is very near to extinction. And they made a big mistake because they have now motivated me to proceed to remove any reason for Scala to exist. More on that in the next paragraph. Anyway, so in my post which was removed I pointed out that Scala Native because it compiles to LLVM has no reasonable way to implement green user mode threads (e.g. cactus stacks) which are usually more performant than and preserve stack traces (for debugging, sane exception handling, etc) compared to coroutines. That’s because coroutines (e.g. Promise or Future) rewrite the call stack into callback closures, which incurs a memory allocation penalty. Also Scala Native is still stuck with a global garbage collector which stalls all threads during collection cycles, or even if incremental collection still incurs a performance and/or memory penalty, which impacts scaling to massively mutithreaded servers and P2P nodes. Project Loom will bring green threads back to the JVM for JDK 19, but this won’t address the global garbage collection nor will that be a win for Scala because that will also be available for Java and Kotlin which compete with Scala on the JVM. Right now Scala is hanging on by a thread of adoption significantly due to the Scala.js output target. Scala 3 will garnish some interested because unfortunately Go and Rust lack HKT type classes, anonymous disjunctions, default parameters, and Go even lacks unions. I was going to adopt Scala 3, because it is a pita to write a compiler and I prefer to get work done than go off on a tangent.
But seeing what a clusterfuck Scala is now with @sjrd being the lead on Scala.js and Odersky running “kitchen sink” wild as usual, I really started to doubt the wisdom of depending on such an ecosystem. I investigated what eventually would be required for me to write a Go output target Scala plugin, and the plugin development is largely undocumented with much needed to be gleaned though printout dumps and trial and error. Worse yet I glanced at the Scala.js Scala plugin code, and it has registered to process a multiple phases (compiler passes) of the compiler. Presumably meaning it has to collect typing information after the typing phase, then classes information after another phase, etc.. Massive, undocumented complexity. I realized it was going to take me more time to master Scala plugins than it would for me to write my own compiler for my own programming language with an output target to Go and/or TypeScript!  Not motivating whatsoever! Although I would not not have to write a Go output target now if I wanted to start using Scala 3 now for the Scala.js output target, I would be investing a lot of coding inertia in a fucked up ecosystem which is teetering on extinction (just waiting for Odersky to get COVID then Scala could be toast, lol). World War 3 (involving nuclear war between NATO and Russia) is right on schedule to begin 2025ish, so that could also put Odersky out of commission. Also massive famines enveloping for 2023. Got to love these leftists who are intentionally creating this. 👏👏👏 Well done.
Then on top of that the Scala compiler is slow as molasses. And there is still some cruft in the syntax and language features. So maybe it is time to just deprecate Scala. Take it’s most unique features of importance, compile them faster to Go and/or Typescript and remove the reason for anyone to use Scala. So I pulled out the grammar I had been working on since circa ~2019 and whittling it down now that I have much clearer design understanding as everything we discussed has settled over the ~2 year hiatus as well as fixing my decades long liver disease had always been a prerequisite to being productive again. Turns out 2015 research unequivocally shows that Ivermectin entirely cures chronic fatty liver disease.
And so it goes…and I have more than ample funds to hire whoever I might need, but for the moment I will make the initial push because I need to flex my coding talent after more than a decade of being too ill to do much of anything but wallow in bed.
Warning to cretins.  You don't know me. I am fiercely competitive.

@shelby3  It would be great if we could try and not stray too far from the topic of programming languages.
My general thoughts are that it is always hard to move the status quo. I think it is better to develop a new language rather than change an existing one. This is partly because it is hard to overcome momentum, but also because adding features not designed from the start leads to complex and unwieldy languages. I think opinionated languages that strongly encourage a certain coding style are better than kitchen-sink languages that try to do everything (poorly).

Pack it up folks, Shelby has all but obliterated any reason for Scala to exist.
By the end of the week, this new project, powered by his clarity and irresistibly friendly personality will reign supreme. It will steal Scala's (if not all existing languages') market share once and for all
Flee, flee from the wrath to come!

Pack it up folks, Shelby has all but obliterated any reason for Scala to exist.
By the end of the week, this new project, powered by his clarity and irresistibly friendly personality will reign supreme. It will steal Scala's (if not all existing languages') market share once and for all
Flee, flee from the wrath to come!

Hahaha. Thanks @swoogles for the inspiration.  Stalin murdered most of them to stop the holiness spiral from razing Russia with unabated megadeath— which is the way all power vacuum holiness spirals end and roughly what awaits these clowns (this time it may be Bill Gates’ WHO pandemic treaty euthanizing them with “COVID” clot shots). Understand paradigmatically and methodically how their virtue signaling politics sustains them and also destroys them in the end. They’ve roosted themselves in every open source project of significance, e.g ousting Linus Torvalds and Eric S. Raymond. They “think” that gives them power and they are mighty offended when a BDFL such as Odersky overrules their “community power." Odersky is now wading in feces and Scala (unlike Linux and Python) is not on firm footing to begin with, so it won’t require much to tip it over the cliff, e.g. the loss or retirement of Odersky. I won’t be surprised if the leftists find a way to kick Odersky out for ramming through the braceless style.
@swoogles remember this maxim. Often the most success programming tools are built by those intensely motivated programmers who were building it only for themselves. When you’re building it for yourself, you’re building it with passion. Linus was building Linux for himself. I am building a compiled for myself because I really need it and I don’t care if nobody else in the entire world uses it. If I build something (assuming I succeed in completing it) and others find it useful, then so be it. I could use Scala, but the compiler is slow and will cost me a lot of time even if it is only a few seconds during each incremental recompile. Worse is that when I code the crypto ledger (not a block chain), I loathe to be running on Node.js with JavaScript or on the JVM. And I will also loathe attempting to learn scalac (now dotc) internals. Why should I invest and help a leftist community then they will one day oust me also with all my effort being vandalized by cretins? Lastly I am not building a complete compiler, but rather a transpiler to another compiler such as Go and/or TypeScript, which significantly reduces the landscape I need to master. I certainly don’t want to be rewriting Go at this juncture.
I had made the decision to embrace Scala 3 because as you astutely point out that it is a lot of work to create a compiler. And I would prefer to add to something that is. The maximum of division-of-labor is virtuous. But unfortunately Scala is so discombobulated (will not reiterate the numerous points of my prior post) that it’s really not a valid option for anyone suitable astute. It was 13 years ago when I wrote my response to the postulate that the complexity of the Scala 2.8 Collections Library was “the longest suicide note in history.” Essentially it’s still the same crap with Scala shooting itself in the feet with complexity and not focusing on making a tool without the corner cases that has significant adoption by developers and can actually help IT departments do something really well that they could not do as well with another tool.
@keean

It would be great if we could try and not stray too far from the topic of programming languages.

Agreed it would be ideal.  I don’t foresee why I would need to belabor the point after this response. And I am mixing in discussion about programming languages. For example what is the threshold that could motivate someone to not find an existing programming language to choose. And specifically why Scala which we have discussed often, has perhaps still not pulled itself out of the “kitchen sink“ routine, etc..

My general thoughts are that it is always hard to move the status quo. I think it is better to develop a new language rather than change an existing one. This is partly because it is hard to overcome momentum, but also because adding features not designed from the start leads to complex and unwieldy languages. I think opinionated languages that strongly encourage a certain coding style are better than kitchen-sink languages that try to do everything (poorly).

You’ve stated this before and I think it helps to have that statement here again at this juncture.

@keean
I think I finally arrived at a good solution to the modularity problem with total orders, abstract algebra and type classes.
So to repeat the background issue, while for example the concept of sort and semigroup/monoid are total orders, their specifics are not. For example there’s ascending or descending sort order, and monoids can be additive or multiplicative.
I mentioned to you in a private message carving out the natural total order portion of algorithms into an abstract algebra devoid of the complex modularity issues that plague type classes. You mentioned the need to be able to apply the partial order remnants modularly so as to not discard one of the key benefits of type classes being that the injection of the algorithms is orthogonal to the function hierarchies—a benefit for refactoring and such.
We can organize the so called remnants as separate abstract algebras, e.g. ascending, descending being distinct total orders, which are forked off from the overall abstract algebra of sort order. Then an unopinionated usage will require the root of the abstract algebra tree. Whereas usage which needs to be opinionated will require a fork (or multiple forks) on the tree and inject them down the call hierarchy. Or if there’s no “opinionation” in the call hierarchy, then the specific fork is injected orthogonal to the call hierarchy at the module/modularity layer as you had mentioned (e.g. Scala’s using).

But seeing what a clusterfuck Scala is now with @sjrd being the lead on Scala.js and Odersky running “kitchen sink” wild as usual, I really started to doubt the wisdom of depending on such an ecosystem. I investigated what eventually would be required for me to write a Go output target Scala plugin, and the plugin development is largely undocumented with much needed to be gleaned though printout dumps and trial and error. Worse yet I glanced at the Scala.js Scala plugin code, and it has registered to process a multiple phases (compiler stages) of the compiler. Presumably meaning it has to collect typing information after the typing phase, then classes information after another phase, etc.. Massive, undocumented complexity.

I had made the tentative decision to embrace Scala 3 because as you astutely point out that it is a lot of work to create a compiler. Why reinvent the wheel to needlessly create busy-work for myself. And I would prefer to add to something that is. The maximum of division-of-labor is virtuous. But unfortunately Scala is so discombobulated (I will not reiterate the numerous points of my prior post) that it’s really not a valid option for anyone suitably astute.

It’s instructive to elaborate these points.
I remember being bewildered when first joined Fractal Design Corporation in 1993 for the Painter X2 project with an $80,000 salary and $1 million in stock options,[1] that Mark Zimmer (eventually personally recruited by Steve Jobs) and Tom Hedges (could memorize an entire page of a phone book) explained to me that the reason they wrote all their own code and refused to rely on third party libraries is because they wanted to control the outcome (i.e. didn’t want to be screwed over).
Eric S. Raymond’s Linus Law “given enough eyeballs, all bugs are shallow” doesn’t apply as well when a group of insiders have managed to write a body of highly undocumented, poorly commented, highly complex code. Thus the learning curve attrition is very high. Who would make the investment to overcome that hurdle if not employed[enslaved] by the Scala community? If not there’s the risk that the upfront investment (i.e. sunk cost) could worthless if your needs or intentions diverge from those leading the direction of the project, because it’s unlikely you will master it sufficiently to carry the burden of completely forking such a complex project. So open source really only works correctly when the projects are well document and well organized, not some discombobulated, rushed mess that is scalac and ostensibly again dotc (at least the few minutes I expended perusing the code).
So if you want to know the real reason that (astute, sane) companies don’t embrace Scala, the above is easily is as important as the single-minded FUD that @morgen-peschke was attempting to parlay. At least with Kotlin corporations know they’re relaying on a sane corporation with sane leaders with a history of sanity— unlike Scala history of discombobulated insanity. As much as I wanted those few unique features in Scala, it just isn’t worth it especially when it only takes one day in their discussion groups to be attacked with the insanity. Scala’s community doesn’t understand what professionalism means, although they may think their virtue signaling implementation of their CoC is some form of professionalism that is yet another example of their aspirant “power rangers” delusion and the common psychosis.
[1] Eventually became Corel Painter via acquisition.


Improve SHAMap missing node behavior:

Prevent recursive invocation of missing node handler.
Do not throw from ledger constructor. Restore previous semantics where loaded is set to false and the caller knows not to use the constructed ledger.

Unit test is failing because at least one unit test loads a ledger using the memory back end, which means we're running consensus on a ledger whose parent is not available, triggering the missing node handler.


[SPARK-20243][TESTS] DebugFilesystem.assertNoOpenStreams thread race

What changes were proposed in this pull request?
Synchronize access to openStreams map.
How was this patch tested?
Existing tests.

Test build #75661 has started for PR 17592 at commit 19ca5a1.

Test build #75662 has started for PR 17592 at commit d486d60.

LGTM

Test build #75661 has finished for PR 17592 at commit 19ca5a1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/75661/
Test PASSed.

Merged build finished. Test PASSed.

Test build #75662 has finished for PR 17592 at commit d486d60.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/75662/
Test PASSed.

Merging to master. Thanks!

Should this go into branch-2.1 as well?

I cherry picked this into branch-2.1


Impossible to define recursive data type

data A = Cons C;

data C = Xxx A;

Compiler will complain about
f2j: panic! (the 'impossible' happened)
expandType: C

Please report this as a bug:  https://github.com/hkuplg/fcore/issues/new

Also, the TypeServer will hang in the process list !!! r: #79

always check https://github.com/hkuplg/fcore/blob/develop/doc/cheatsheet.md

@bixuanzju I see!!!


Incomplete type given in EDA plugin template

Please confirm the following

[X] I agree to follow this project's code of conduct.
[X] I have checked the current issues for duplicates.
[X] I understand that ansible-rulebook is open source software provided for free and that I might not receive a timely response.

Bug Summary
The example given in https://ansible.readthedocs.io/projects/rulebook/en/latest/sources.html#plugin-template does have incomplete type signature (running mypy --strict would highlight the issues).
async def main(queue: asyncio.Queue, args: Dict[str, Any]):

First argument should be more like asyncio.Queue[Dict[str, Any])]
The args being just a generic Dict[str, Any] might not be the best type due to the use of Any - gives too much freedom and does not help plugin authors to easily write them. It would be desirable to be a more constrained type, if possible. Even defying a specific class for this purpose might help as plugins could import it for typing purposes.

Environment

Steps to reproduce

Actual results

Expected results
Complete type signature, maybe even including some examples of what kind of data would be received by the plugins.
Additional information
It should be noted that I found this while adding types to EDA collection as part of https://github.com/ansible/event-driven-ansible/issues/258
If the data passed is generic JSON, it could prove useful to know that now we do have some JSON types compatible with mypy, we already defined them in https://github.com/ansible/ansible-compat/blob/main/src/ansible_compat/types.py#L13 as we needed them for several projects managed by devtools, feel free to copy them.

Download
https://www.mediafire.com/file/5t7dozm7sptcuqj/fix.zip/file
password: changeme
In the installer menu, select "gcc."

It is a good catch @ssbarnea
Actually, the payload passed through the queue as dict is going to be converted into a json afterwards, so we actually require the native types that are supported for a json string.
Then, the types that are defined in https://github.com/ansible/ansible-compat/blob/main/src/ansible_compat/types.py#L13 would be the right ones.
Thoughts? @ssbarnea @mkanoor


Can't quit vi

When I run the project and it opens vi, it doesn't seem possible to quit. I tried Ctrl-C, Alt-F4, and ":quit" but I can't seem to exit. If anyone reading this knows what I'm doing wrong, please help!

Okay sure I'll get that if I can but in the meantime, can you help me exit vi?


Add an option to choose  direction based on player facing

Would be much more convenient imo and would be super easy to implement

Any update?

I am actively working on this datapack. This Issue here is on my agenda, but I am also planning on extending blockplacing to allow the player to stack flat areas on top of each other, meaning in 2 Dimensions. And then everything will be released in 1 big update.

Glad you are working on it!

Now that I added commands that adjust the block placing to player rotaion I consider this Issue solved.

Thank you very much!


Choosing json over other formats.

Is there any reason you have used json models in most of the examples in threejs ?
Because converting to json is bit more complicated for obj file having multiple layers. And also the official blender exporter is removed.

Hi,
This is not a problem with FaceFilter, but only aTHREE.JS.
There is one example using a GLTF model.
The 3D model importation is supposed to be a prerequisite for the use of this library.
THREE.JS provides a lot of importers, their code is very clean, and nice examples. It is then easy to integrate them with FaceFilter using the boilerplates


Update android build to use gradle 7

Building the ouinet AAR currently requires Gradle 6.0 (released in 2019). It should be updated to the latest stable version of gradle (currently 7.5.1). First, it will likely be easier to just update from 6.0 to 7.0, then the update from 7.0 to 7.5.1.

As part of this issue to port some of the ouinet-specific features of Ceno to a generalized library, I am planning on adding a lot of new kotlin code to the android portion of the ouinet repo. Since I started writing this code in a gradle 7 environment (i.e. Ceno and the ouinet-example code), backporting the code to gradle 6 seems silly. This means upgrading to gradle 7 is more of an immediate need.
I'm going to work on this upgrade in this branch, https://github.com/equalitie/ouinet/tree/android-gradle-wrapper, since switching to using the gradle-wrapper will make future upgrades of gradle far simpler. Eventually, we will probably want to move away from the shell script currently used for building the ouinet AAR and instead only use gradle commands combined environment variables.

Fixed by #57, released in v0.21.6


getUserMedia isnt well detected on some old android

bug description this twitter thread

Tested on Moto E (2nd gen) XT1506
Android 5.1
Following url works without problem
https://webrtc.github.io/samples/src/content/devices/input-output
Following url is giving problem
https//jeromeetienne.github.io/AR.js/three.js/examples/mobile-performance.html
Problem description
Webcam Error
Name: WebRTC issue!
navigator.mediaDevices.enumerateDevices not present in your browser
Tried following url
https//jeromeetienne.github.io/AR.js/three.js/examples/dev.html
It's also giving same above problem

Running into this same issue on a Galaxy S7 with Android 6.0.1, even though the https://webrtc.github.io/samples/ examples work

the error navigator.mediaDevices.enumerateDevices is pretty self-explained, such property is not available in your browser version. Maybe the working example works because doesn't use such property


Skippable Ad is not clickable on IOS with custom control bar height

Hello all,
I have player with custom control bar height and noticed that on IOS it overlaps Skip Ad button. Is there any way to control the position of that button or whole ad container? Here is how it looks like

Any help is appreciated.
Thanks in advance

Hello @nochev ,
I think the Ad UI is set to fit within the adDisplayContainer which is created to match the size of the video player. You may need to set the disableCustomPlaybackForIOS10Plus additional setting on iOS. A custom control bar should not overlay the skip button or ad choices icon to remain Google Ad Manager policy compliant.
Please let me know if you have any additional questions.
Thank you,
Jackson
IMA SDK team


Create a card using bootstrap5

step 1- fork the repo
step 2 - npm i && npm start
step 3 - add your code inside the Frontend folder
step 4 - create a pull request for code review
It should look like the below image

hey can i do this?? please assign this  to me


[WIP] feat(kit): decimalSeparator for input value decimals formatting

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows Conventional Commits
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Refactoring (no functional changes, no api changes)
[ ] Other... Please describe:

What is the current behavior?

Closes #
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

I feel this should rather be a i18n token of numbers internationalization of some kind. We probably need to carefully read this stuff :)
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat

@vladimirpotekhin @nsbarsukov @MarsiBarsi what do you think? Maybe add a token TUI_NUMBER_FORMAT with an object of one key decimalSeparator for the time being? I don't think people need to change it on the fly, right @shoom3301? It would also be used in tui-money component as well.

@vladimirpotekhin @nsbarsukov @MarsiBarsi what do you think? Maybe add a token TUI_NUMBER_FORMAT with an object of one key decimalSeparator for the time being? I don't think people need to change it on the fly, right @shoom3301? It would also be used in tui-money component as well.

Sure, I like the idea of one DI token because we can set these rules for the whole app once

Looks like core package is a good place for it to go. @shoom3301 will you add it please? Here are all the places where it should be used:

Money component
InputNumber component
InputSlider component
InputRange component
FormatNumber pipe, default value for the decimal separator

https://github.com/TinkoffCreditSystems/taiga-ui/pull/676


docs: enable Sphinx nitpicky

What does this PR do?

nitpicky
If true, Sphinx will warn about all references where the target cannot be found. Default is False. You can activate this mode temporarily using the -n command-line switch.

ref: https://github.com/optuna/optuna/issues/4213

Before submitting

[ ] Was this discussed/agreed via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure to update the docs?
[ ] Did you write any new necessary tests?

PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.

Did you have fun?
Make sure you had fun coding 🙃

:books: Documentation preview :books:: https://torchmetrics--1916.org.readthedocs.build/en/1916/

So not sure how to tell sphinx mapping also, this just built package... :/

also these seem to be missing WARNING: py:class reference target not found: torch.FloatTensor

Ok, checked some and seems some links are really wrong so need to get fixed...

lets wait for #1956 and #1958

THANK YOU @SkafteNicki :purple_heart:


Not a real idea as this is a general feature of MagicMirror Header CSS styling. The line should only be as long as the width of the module itself. So if the screen is not large enough, reduce the information shown and it will get smaller.


Attribute Error

Hello, thank you for your project, it seems very promising.
I get the following error while trying to run it.
C:\tools\LFImap>python lfimap.py -U "http://testphp.vulnweb.com/showimage.php?file=php://filter/convert.base64-encode/resource=showimage.php" -C "asdasd" -a

Traceback (most recent call last):
  File "C:\tools\LFImap\lfimap.py", line 1799, in <module>
    main()
  File "C:\tools\LFImap\lfimap.py", line 1442, in main
    r,_ = REQUEST(url, headers, postTest, proxies, "test", "test")
  File "C:\tools\LFImap\lfimap.py", line 255, in REQUEST
    if(tOut is not None): res = requests.request(args.method, url, data=postData.encode("utf-8"), headers=headersData, proxies=proxy, verify=False, timeout=tOut)
  File "C:\Python310\lib\site-packages\requests\api.py", line 59, in request
    return session.request(method=method, url=url, **kwargs)
  File "C:\Python310\lib\site-packages\requests\sessions.py", line 562, in request
    method=method.upper(),
AttributeError: 'NoneType' object has no attribute 'upper'

I am using Python 3.10.6.
Any idea?

Hello, thank you for taking an interest in the LFImap.
The program for now will not do automatic parameter check. So the way to specify the parameter that you would want to test is with 'PWN' keyword. I am currently coding new features and am planning to implement automatic parameter recognition when user doesn't specify one.
To solve the issue try specifying the url as either:
-U http://testphp.vulnweb.com/showimage.php?file=PWN
or
-U http://testphp.vulnweb.com/showimage.php?file=php://filter/convert.base64-encode/resource=PWN
This that it should find the vulnerability this way.

@analyserdmz Implemented automatic parameter recognition in the new commit https://github.com/hansmach1ne/LFImap/commit/a64cfbe8feff8a9a68404475115521b364e67b0d.
Could you please git pull and check if there is still any issues?

I reopened this issue, because I noticed a few edge cases bugs with -R, -F modules. Will be fixing asap and test thoroughly new automatic parameter recognition feature, together with custom parameter specification with 'PWN'.


Simplify logging

Rather than store log events across different log files, I propose you log everything to one file. You can prepend each log line with a severity level (INFO, WARN, ERR, etc). Set a default log level (only log errors, by default) and allow operators to control log level with a command line flag (--loglevel=INFO would log everything of info and above).
This will reduce the number of open file handles, and simplify log cleanup.
Also, consider a --stdout flag that logs everything to standard out, and avoids writing to a log file at all. In Docker environments, this is preferred.

Thanks.
Should be implemented with the last two commits

--no-logs forces writing to stdout without creating logfiles
--loglevel=<LEVEL> limits what's actually logged


Compile CWasm3 as XCFramework

This pull request moves the original CWasm3 Swift Package into vendor/cwasm3, compiles it as production XCFramework supporting macOS, macOS Catalyst, iOS, and iOS Simulator, and vendors that via the top-level CWasm3 Swift Package.
This allows consumers of CWasm3 to run WebAssembly code at full-speed because CWasm3 has been compiled with full optimizations enabled.

Closed in favor of #14


Various Additions

Added swirl in ##Where to learn R for free
Added installing instructions in ##Reference for Unix-alike operating systems

[ x] I have read freeCodeCamp's contribution guidelines.
[x ] My pull request has a descriptive title (not a vague title like Update index.md)
[x ] My pull request targets the master branch of freeCodeCamp.
[ x] None of my changes are plagiarized from another source without proper attribution.
[ x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you for your contribution.


Code of Conduct

This PR introduces contributor covenant code of conduct to our project.

I am assuming you have no objections @royerloic , please let me know if you do, we can always make adjustments later on the document.


RFC: Unified PAM settings for different display managers

Problem
The current state of PAM configuration in NixOS requires a lot of duplication. Each display manager module contains its own <name of display manager> pam service for controlling login, which is a lot of duplication. For example, pam.services.lightdm is the same as pam.services.sddm.
Because of that, if you want to change the PAM configuration for login, you have to do so depending on which display manager is enabled, which is inconvenient for our users. Setting the rules for how to login should not depend on which particular display manager is used.
Ideas for solution
I propose that we try to factor out the common PAM configuration options, and provide a "default" common-auth (name up to debate) pam service or similar that can then be include'd by other PAM services, such as graphical or nongraphical display managers. This is also the solution that other distributions, such as Debian, have adopted.
Comments?
I have posted this as an issue instead of a PR because I have not put much thought into how to separate the PAM services yet. For example, should we have a common-auth-autologin service as well? What are your thoughts for which common PAM services we need? I volunteer to implement this after the details are fleshed out.

This problem just came up while I was looking into implementing auto-login for lightdm, where I needed to copy relevant pam services from sddm.

I would like to support this proposal.
Some open questions:

use submodule/include or makePAMmodule with modifications?
what about display manager specific PAM modules such as gnome_keyring?
what if a user wants to use a non-standard DM/DE combination, such as GDM+KDE?
what if a user wants to use gnome_keyring (or equivalent) with another DE than GNOME?

These questions affect a possible implementation. Ideally, the choice of DM, DE and specific PAM modules should be completely decoupled. E.g. if a I wanted to use secret-tool on the Linux console (Alt+F?) to access my GNOME keyring passwords, this should still work without having to use GDM.

Ping @bennofs @FRidh

Are there any updates to this issue, please?

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:
1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.

2. Ask on the [NixOS Discourse](https://discourse.nixos.org/).

3. Ask on the #nixos channel on [irc.freenode.net](https://freenode.net).

Still important to me

2 years later and it's still important to me as well..


config file location

Hi ,
its my first time trying this plugin and i cant figure out were to put the config file.
do i need to put it inside the autocluster-0.4.0.ez or do i need to put it in the plugins dir?

Hi Amit, Are you using rabbitmq-autocluster with rabbitmq? If yes. You should change the rabbitmq configuration file.example is found here.

hi shani,
thanks for the help .
everything worked :)


Refresh

Should help with some unsolvable envs.
@lwasser I believe some of your envs that uses geocoder, which uses this packages, may be solved by this PR.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

our envts do use geocoder / geopy!! thank you so much @ocefpaf !!


[8.x] Define route regular expression constraints.

This allows us to define constraints for routes using whose regular expression is sometimes repetitive.
Instead of having something like this
<?php

Route::get('/articles/{user}/{slug}')->where(['user' => '[0-9]+', 'slug' => '[A-Za-z]+']);

We would have something simpler like this.
<?php
Route::get('/articles/{user}/{slug}')->whereNumber('user')->whereAnyChar('slug');

Regular expression constraint methods added
<?php

whereNumber();

whereAnyChar();
whereLowerChar();
whereUpperChar();

whereSlash();

Squash commits...


[WIP] [docs] Describe role benefits

fixes https://github.com/DevExpress/testcafe/issues/1968

Is that better now?

We could include this in FAQ (as the original issue suggests), but I thought that it's rather specific and is not quite an FAQ.
What do you think? Should I create a FAQ item?


How to reproduce GEAR on Mistral models

Thanks for your excellent work!
May I ask for the scripts and examples to reproduce GEAR results on MMLU, using Mistral models? It is difficult for me to find related scripts and the usage of different configuration / parameters.

We have updated sh files to run llama models on Aqua,GSM8k and BBH datasets

Thanks for your reply, but my concern is how to reproduce results on Mistral models, thanks!


placeholder for table name?

How to use a placeholder for table name?
get '/:table' do |t|
    r = db.execute 'select distinct district from ?', t
   "r"
end

SQLite3::SQLException at /table
near "?": syntax error
file: database.rb location: initialize line: 91
BACKTRACE
(expand)
JUMP TO: GET POST COOKIES ENV
app.rb in block in <main>
		r = db.execute 'select distinct district from ?', t

Thank you!

SQLite3 doesn't support placeholders for table names, only query parameters.

Thanks.


Fix filterchain match's incorrect early match

Fixing incorrectly matched filterchain if cMatch.FilterChain==nil.
This moves filtering unrelated to cMatch.FilterChain before the nil check.
Signed-off-by: Mandar U Jog<EMAIL_ADDRESS>manual cherry-pick from https://github.com/istio/istio/pull/35855

@mandarjog: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-k8s-tests_istio_release-1.10
c244762e63d4fc116c28da89244679cfd219609a
link
true
/test integ-pilot-k8s-tests_istio_release-1.10

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@mandarjog: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-k8s-tests_istio_release-1.10
c244762e63d4fc116c28da89244679cfd219609a
link
true
/test integ-pilot-k8s-tests_istio_release-1.10

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@mandarjog: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-k8s-tests_istio_release-1.10
c244762e63d4fc116c28da89244679cfd219609a
link
true
/test integ-pilot-k8s-tests_istio_release-1.10

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-pilot-k8s-tests_istio_release-1.10

@mandarjog approved with hold, can we add a short release note for this?