Rhombus massively advances the state of the art for macro systems in infix languages. Macros in Scala, Rust, and Elixer are extremely limited compared to Rhombus macros. The enforestation-based approach that Rhombus uses and the underlying Racket macro machinery means that things like Rhombus's class system, pattern matching system, annotation system, infix operator system, etc. are all implementable as macros. That's definitely not the case in Scala, Rust, or Elixir. Imagine if the base Rust language included only a macro system and `unsafe` code and the borrow checker could be implemented as a regular library in `std`.
Are you familiar with `syntax-rules` based macros? Because this is roughly the same logic here.
It's trying to unify how macros produce syntax objects via `syntax-rules`-style pattern matching and ellipses with how regular pattern matching on values works, so there aren't two separate pattern languages (one for macros and one for everything else).
This is not a disagreement on political positions, this is a belief that women are inherently less capable than men at software engineering. It's a direct attack on the legitimacy and humanity of his coworkers. A disagreement over political positions would be if the author wrote a manifesto about the efficacy of sin taxes or nuclear treaties, not that his teammate Sandra is biologically inferior at her job and undeserving of it.
Other programming ecosystems are at least an order of magnitude smaller and not intrinsically tied to technology that's in relatively extreme flux with a massive amount of users (browsers).
The "Racket VM" is designed from the ground up for other languages to be built on top of it (hence the #lang line at the beginning of every file) so it would likely be much better. Hackett[1] is a Haskell-like lang built on top of racket, for a nontrivial example.
> We did what we always do when there's a problem without a clear solution: we waited. Waiting gives us more time to add experience and understanding of the problem and also more time to find a good solution. In this case, waiting added to our understanding of the significance of the problem, in the form of a thankfully minor outage at Cloudflare. Their Go code timed DNS requests during the end-of-2016 leap second as taking around negative 990 milliseconds, which caused simultaneous panics across their servers, breaking 0.2% of DNS queries at peak.
This is absurd. Waiting to fix a known language design issue until a production outage of a major customer is a failure of process, not an achievement. The fact that the post presents this as a positive aspect of Go's development process is beyond comprehension to me.
Note that at no point in the post whatsoever were any contributions to these specific issues from outside the core maintainers thanked or even acknowledged.
It's worth noting that the argument against call/cc is specifically against undelimited continuations. Delimited continuations, such as those created by the `shift` and `reset` control operators, do not suffer from the problems of call/cc.
Then why does their behavior disproportionately affect women, who have less power to complain about their behavior? If this were entirely an aspect of their character or personality they'd be an asshole to everyone equally, not opportunistically take advantage of people who have less ability to stop them.
I think the default storage format Hypothesis uses is a flat file with a diff-friendly format so it's easy for developers to check it into source control, and it's easy for patches to update the database without exploding the git repo size due to giant binary diffs. Sqlite3 might also be an option but I'm not up to date on the details. As a neat side effect of the diff-friendly format, it's easy to review new falsifying inputs added to the database in pull requests.
Some property testing tools like Python's Hypothesis[1] allow specifying specific example values for properties in addition to a general set of values so you get some specific deterministic tests. Hypothesis also saves falsifying values it found previously in a database that it reads from the next time you run it.
It's hard to tell from a cursory overview, but I'm pretty sure L2's macro system is roughly equivalent to "fexpr" based macro systems used by some other lisps and schemes.
Typed Racket runs after macro expansion, performing analysis on fully-expanded code. This technique runs as part of macro expansion, rather than after. The upshot is that macros get to use and generate type information, so language and type system features like typeclasses or GADTs can be library-provided macros.
I wouldn't call it a grand plan, but it is one of Google's five officially supported server languages and as a result there's a lot of work being done to build tools and libraries for it. Code generation and relying on language-agnostic building and packaging systems (bazel) are both pretty common Google-isms, which show how the company's development culture influenced the priorities and direction of the language.
Go has one of the largest tech companies on earth actively pushing it and pouring countless programmer hours into developing tooling and support for it. That pretty much trumps all of its misfeatures in terms of gaining adoption.
If you don't use networks then all services are on the default network and can refer to each other by service name, so even without complicated full-blown networks links are superfluous.
HATEOS, and REST in general, is a lot more useful when there are middlemen involved. If I have some link relation type named "api.myservice.com/rels/access-controlled-by" and some content type for authentication policies, then I can build a proxy between my API and clients that looks for links of this relation to resources of this type and automatically implements authentication checks. Instead of writing code to check auth rules in my API, I link to a resource that the auth proxy understands in a common format. This format can evolve over time without breaking the proxy due to content negotiation, and API services written in entirely different languages can still rely on a uniform implementation of authentication rules.
There's all kinds of other directions you can take this including quota enforcement, monitoring, auditing, and other resource-agnostic concerns. More radically, you can make these sorts of proxies reusable services that other people rely on to implement these behaviors. One of the primary motivations for REST in the first place was a standard interface that would allow for insertion of caches at arbitrary points in the Web without breaking everything (in the optimistic case at least). There's even HATEOS in the Cache-Control header, as the cache channels extension uses links to external resources to define the cache channels for resources
If your requests are "POST to create something" requests, you can get a more REST-ful flavor of idempotency by turning the POST into a redirecting GET followed by a PUT to emulate two phase commits.
Instead of POSTing to /transactions, I GET /transactions/fresh (optionally a URL linked from /transactions to avoid assumptions about URL structure and capabilities) which generates a unique ID and redirects to /transactions/{some-unique-id}. Attempting to GET that transaction would return 404 as it doesn't exist yet, but I can PUT to it to write a transaction. Now I'm using only idempotent methods instead of POST, and I don't need to figure out how to properly construct and manipulate a token in a header, and proxies don't need to know about this special header to know requests are idempotent since the methods I'm using communicate that already.
This adds a minimum of one extra request to all two-phase resource creations. If your goal is to retry safely though, the number of retries could dwarf that overhead. It all depends on how likely it is that failures actually occur. Client-side ID generation removes the extra request but brings back the problems of clients needing to understand URL and ID formats and construction logic.
Hi, Racket community member here. Thanks for the in-depth comment about your experience, and thanks for writing about your work with the webserver library! A couple follow up questions if you've got the time:
1. Could you elaborate on the stacktrace issues you encountered?
2. The Gregor package [0] is currently a bit of a community standard for date and time functionality. There's a general desire to merge this into the Racket stdlib. Would this package suit your needs?
3. For string templates, a lot of folks use Scribble "at expressions" via the `at-exp` meta-language combined with format specifiers from `racket/format` to write code that looks very similar to python string interpolation and other language-integrated string formatting systems. You can see an example of that on Greg Hendershott's blog [1]. Would this work for your use cases or were you looking for something a bit more involved?
> Whether these restricted languages are doable as embedded DSLs in general-purpose language remains to be seen
I'd argue that the Racket language (or language platform, depending on your view of things) shows it's possible with its #lang mechanism and macro system. For example, though Racket proper is untyped, Typed Racket is implemented as a #lang with macros and includes an optimizing compiler that removes runtime checks on programs that typecheck successfully.
I think there's a tendency in the Racket community to rely much more on a thorough reading of manuals and docs than a peek at the source code. I personally can count on one hand the number of times I've had to look up implementation code for debugging or to figure out how to implement something. The Racket manuals, Scribble, DrRacket's integration with both, and the strong culture of documentation in user packages make for a wonderful development experience.
This is a very crucial point. The so called "stupid" financial behavior of people in (first world) poverty is anything but, it's a series of carefully calculated and measured responses to extreme inflexibility. Almost all means of establishing long term financial stability involve either a) put away some money now, wait for some time, then receive more money or b) risk losing some money for the chance to gain more money in a way that averages to a net positive over time. Neither of these are possible when you do not have flexibility, you can't afford to put away money when doing so means not eating for a week, and you can't afford to risk money for more money when coming out on the losing end of that deal means becoming homeless. You have to have a completely different approach to managing money when in poverty, and it sticks with you mentally even after escaping to a more stable situation.