hurril

All four of these are awesome tips, thank you!

Do you have anything in particular in mind here? Long time macOS user but I like a good pro tip :)

Right and C has a special place in my heart. I have never coded C in anger, but the weird thing about coding in Java is how low level all the implementations are. I've had this debate/ conversation with people over the years and I realize that if I am the only one at a certain position, then I am wrong and not everyone else.

But I claim that Rust is actually a high level language. Higher level than Java. My argument is that in Rust (, F# and Scala) you can encode in structure, what has to be operational code in Java.

So in the stronger languages you can reason about larger swaths about domain concepts easily, whereas in Java you have to trust the test panel on faith and wade through deep sections of "magic code" (compare with magic numbers. Why is there a 427/ these 7 lines of logic here? What does it do?)

I am not. I am saying that had I been a good little Java/ C# developer, then I would never have learned Rust and all of the things that come with that.

Scala is not doing great, probably because they took too long to get 3 finished and good.

Yes. Companies are going back to Java because this is what all the convervative guys and girls want to use. That fact is what I am criticizing. You want fast horses, you don't want nice things.

So now you have Maven, semi-typed code intermingled with container logic because you cannot abstract over anything, you have millions of lines of impenetrable tests. Just like we all did in 2006. You all love this because learning things is not your forte :) That other stuff is for academics and niche.

C is turing complete so of course. You can do anything with C but that is not the issue we are discussing here.

This is just not true, the last bit you say. That is the same old trope about F#, Rust or Scala being niche, things people that don't have to earn money or feed children can do. I worked 100% in those languages from 2012 through 2023.

But sure, with AI, maybe this will matter less because people don't care about the code anymore.

This rests entirely on the same same sort of conservative attitude towards new experiences that holds the other half of the development world back. The Java world. People generally do not want to learn new things, they want "faster horses", which incidentally is what C# and Java is these days.

This is why we can't have nice things.

Java with Streams and "functions" is a lot better than what I left behind 15 years ago. But it is still extremely primitive compared to what F#, Rust and Scala offers. And I know this because I have spent 10+ years EACH using all of these in anger. So 20+ years.

I guess that depends on what goals you have in mind. If they are producing a correct program, then having the compiler verify your assumptions, forcing you do deal with domain complexity upfront is one way to do that. Tests( driven development) is another one.

But in this context I feel that partial solutions are offered as alternatives to more complete ones. I.e.: if holes in your trousers is of no concern, then having tools to avoid that is of no value.

Not picking on C here, as already mentioned, it is a wonderful language.

Unless you or him define what you mean by complexity, we are not going to be able to come to an agreement there. This line of reasoning, it seems to me, is making the case that C is more complex than Assembly because the former has a number of formalizing, let's say, concepts that are not in assembly.

I would on the contrary say that adding extra static checking deducts from the _actual_ complexity of the domain and its application.

Still not picking on C++ here. I would claim that these concepts pretty much all exist in C++ too, but often implicitly so. You would solve them by "braining them", with good rules of thumb, patterns, tests and deep knowledge and skill. In fact, you _have_ to solve them this way.

In Rust the compiler is going to have a problem with your code unless you are explicit about borrowing/ ownership, gcc won't care. Which is the more complex thing there?

Same goes for the polymorphism. Looking at languages without parametric polymorphism, you instead see casts and inheritance trees. Not picking on old Java here, but is this more or less complex?

Let's talk some about unsafe as well. In C or C++, for instance, there is a global unsafe surrounding all the code, so if someone has problem with unsafe, why would they pick on Rust where "unsafety" is optional?

Same goes for unwrap. Unwrap is basically a deref combined with a _safe_ crash if the deref was not successful at runtime. Do that in an unsafe language and you have an access violation best case. Or just silent corruption. Which is more complex?

I reject the whole Rust has a high complexity premise, but I would gladly continue our conversation around it here but I would need a little more definition for that to be possible.

What do you mean by complexity in this context and in what way does Rust carry a lot of it?

I would argue that what you call complexity here is better referred to as explicit or visible complexity, as compared to hidden or implicit commplexity. The complexity as such comes with the domain and its application; but with Rust you can see it and you are forced to deal. With C++ you can get away with pretending that it is in fact not there.

This is honestly not intended to pick on C++ as a Rust fanboy, however. It really isn't.

For instance, to be a little unpolished, I would shrug off the unwrap incident as doing it the C++ way and pretending that the complexity does not need to be solved right then and there because ItShouldNotHappen or IKnowWhatIAmDoing.

I prefer Rust over C++, but I do not hate C++. This isn't even about C++ anyway.

When it comes to out of control dependency trees, I agree with you. But there is a trade off here too and that is that either you implement the thing or you externalize it. I use both approaches myself and am in no way excusing anything or attempting to be Rust's defense lawyer. There definitely seems to be a leftpad-problem brewing in the Rust community.

I was one of these "smart students" but it really wasn't that I did not want to be there. I was a lazy, or complacent, f*ck. I've have had to learn how to learn and how to have discipline late(r) in life.

Anything in particular that your Linux experience adds over what is available on macOS?

Would the DRM exist without piracy?

This is again conflating at least two things and this is so prevalent in this context. Let us not conflate how annoying DRM:s are to us users that buy the things, with pirates thinking they somehow have a right to use any software without paying fairly for it. I would even go as far as to say that you pirates are the reason I have to have a DRM in the shit I bought and paid for.

I don't think I can agree with you here because a lot of these things that people know but that is supposedly hard to dress in words, is very often just positions that someone holds arbitrarily, so is difficult to impossible to explain. The positions do not have explanations because they are not held for good reason.

I say this as someone with 3 decades of professional experience. That does not make me right, please do tell me that I am in fact wrong! It does mean that I might be one of these guys with positions that should be challenged, however.

You know what? I welcome this. Explain to me why I am wrong, let's do it your way, dear youngin!

I am still an idiot. But driving baked would be impossible :)

I don't see how anyone would even want to attempt to drive while baked.

OCaml is wonderful too but having written F# for different companies for years, my code is pretty much never that hybrid stuff. Sure, .NET:s weird asynch apis, sometimes the code comes out a little bit weird but that is the exception to the rule imho.

Ah F#, my greatest love. How I wish the C# guys and girls would see this instead of further bastardizing (don't hate me) C# into being everything but poorly.

Don't you see that if you would use F# instead, creating projects with C# and F#, that you would get what is being added to C# but actually working and ergonomically? Interop is great!

It really isn't. Having worked for several decades on "both sides", this really is my experience. The functional side is better typed and has fewer side effects of this kind. It is more normal, as in more common, to have code work correctly as soon as it compiles. This is my lived experience having worked with Java, Scala, F# and Rust since 1999.

Well it isn't a good call. This is the kind of code that OOP makes people write.

You have a good point there, that is better. But it is still, well honestly, wrong. Two orders ordered at different times are just not the same order, and using a typeclass approach to say that they most definitely are is going to bite you in the back seat.

PartialEq and Eq for PizzaDetails is good. If there is a business function that computes whether or not someone orders the same thing, then that should start by projecting the details.

An architecture that consists of monads.

See, I don't think you don't really understand my point. I said this elsewhere: I have been programming Scala and Haskell for more than 15 years, which I am sure you have as well. This is not ment as a proof of my point as that would be arguing form authority. This is not my intention. But there are more things at play here.

What I think you are doing is: well quantum mechanics is just simple mathematical construction and some artithmetic.

Is it really? Is it _just_ that?

I am going to interpret your question as one asked in good spirit.

I like this book: https://www.manning.com/books/functional-design-and-architec...

I think that a big problem here is the fact that in OOP, everything is an object, i.e.: a class. And if all you have is a hammer, then .... But it is much better to picture the model, controller and the view as emergent. But implementing this in OOP is too challenging because some things in either of those three domains are going to be a process, or a piece of state or a role, etc.

And in implementing some process, what is it? As in: what is its encoding in $language and where does it go?

So you end up with the local stamp collectors in the office and get into an argument of: it is part of the model, so should be in the Model class. "Process, nah, that is totally a controller aspect. It does something." etc.

You both have good points. But there is monads the mathematical and programmatic concept, and there is also something a little bit handwavy in how these things are incorporated into an application architecture. The latter is what is being used on the one hand in comparison to MVC, etc, on the other.

I.e.: a monadic architecture in Haskell is good, but one in Java is going to suck. A sort of half-way point is in The Elm Architecture, which is a sort of deconstructed IO monad.

(Writing this as someone with decades of experience in writing monadic architectures.)

It runs on .NET, for god's sake. This is not a small platform.