I would also block/reject a person like this. I had my fair share of these phishing attemts so I'm not asking questions if someone is trying to touch my infra.
You can still start with Duolingo. Just know that if you are serious about your language learning, there may be better things in terms of learning per unit time or learning per unit cognitive effort.
Java has exceptions and can mock at runtime using reflection. Go is much worse. If you have glue code that calls 5 methods in sequence, you need to set up build rules to generate 5 mocks for the corresponding interfaces. And then if you’re like me, re-sync the editor so it picks up the generated symbols. Then you need to write 1 + 2 + 3 + 4 + 5 mock expectations for the 5 test cases to reach each error return branch. Oh and the mock expectation arguments are immune to automated refactoring because they’re all interface{}. So if you want to change the arguments of a method that’s implicated in a lot of test cases, lol good luck.
People get over this and even grow to appreciate it from the perspective of the production code, but from the unit testing side it’s been an unrelenting nightmare from the time I started using the language professionally ~10 years ago until we got Copilot.
It’s total slop. Perfect for the slop generating machine.
> And yet HN commenters are easily manipulated into thinking that suddenky oral health is a big driver of pancreatic cancer.
This isn't happening, this is you starting from a solipsist axiom that you're smarter than everyone else, who comparatively must be automatons about receiving information.
OCaml (also SML) has a really powerful module system; it's so powerful that to call it a "module" system is maybe misleading to the average developer. You might think of a "module" system as a way of dividing your program into different files, and the ML module system certainly subsumes that case, but it goes beyond that.
The key to this is that modules in ML are actually kind of a separate programming language. Not only can you define modules, you can define "functor modules" - modules that are kind of like functions; you can pass modules as arguments to functors to produce new modules. And there's a (structural!) type system here, too: the modules a functor can accept are specified to have a specific structure, and if you try to pass an incompatible module to a functor you get a type error.
(Incidentally: the naming of functors in the module system is really unfortunate here, because it overlaps with the name of functors in category theory/Haskell.)
This sounds extremely abstract and kind of insane; it's easier to understand it in practice. A typical example might be that you want to define a hash table, which requires some kind of hash operation for a key. What you'd do idiomatically in ML is define a HashTable functor which takes, as an argument, a module X consisting of a type t and and a hash function. This would generate a HashTable(X) module specialized to that particular key type.
What's interesting here is that there's an overlap here with things like interfaces in Java or typeclasses in Haskell, where your HashTable type would demand that the key type adheres to a Hashable interface. It turns out they're kind of (kind of!) just different takes on the same thing. There's even some interest in the OCaml world in trying to "close the gap" with a feature called "modular implicits" [0].
The other thing to know is that there's an esoteric feature of Haskell called "Backpack", which is an attempt to bring the ML module system to Haskell. It's not exactly widely used or anything like that, but it's there and been in GHC for several years now.
This article is basically just demonstrating how Backpack lets you use modules in much the same way as you'd traditionally use typeclasses in Haskell.
