sideeffffect

20th October, OpenJDK 11.0.9 will be released, with full-fledged Shenandoah GC. It has _very_ low pauses and has the `-XX:ShenandoahGCHeuristics=compact` option, which will promptly give unused memory back to the OS (thus keeping the whole memory profile low).

Give it a try.

https://wiki.openjdk.java.net/display/shenandoah/Main

https://www.slideshare.net/jelastic/choosing-right-garbage-c...

https://twitter.com/shipilev/status/1308320432404168705

According to the blog, BitTorrent v2 now tightens the possible block size to power of 2. But does that still allow for the blocks to be variably sized and created by, for example, a rolling hash-based chunker, like Buzzhash or Rabin?

I'm asking, because this would allow for sharing of big files across swarms, even though the files might be slightly different.

If I understood John's motivation from the video, it's that this enables the Flatten structure to be inspectable, because the innards are not hidden behind an opaque closure (A => F[B]), as is the case in regular Monad.

Btw, this is a problem that the "Selective applicative functor" too aims to alleviate.

You can read more about the inspectability problem (and Selective) at http://eed3si9n.com/selective-functor-in-sbt

The context there is sbt, which is a build tool, but I'm sure the inspectability plays role in many other areas. Note, how he contrasts "Applicative composition" and "Monadic composition".

If you're interested in how Category theory and Algebra can inform the design of software, have a look at ZIO Prelude.

https://github.com/zio/zio-prelude

It's a brand new library for Scala that contains reusable mathematical structures. Still based on algebra and category theory, but it expresses them more or less differently than how they've been expressed in Haskell (and similar languages). For example, unlike Haskell (and Scala's own cats and ScalaZ), it doesn't present the "traditional" Functor -> Applicative -> Monad hierarchy. Instead, it presents the mathematical concepts in a more orthogonal and composable way.

One example out of many, you don't have a Monad. You have two distinct structures:

* Covariant functor, with typical map operation `map[A, B](f: A => B): F[A] => F[B]`

* IdentityFlatten which has a flatten operation `flatten[A](ffa: F[F[A]]): F[A]` and an identity element `any: F[Any]`

When combined together (Scala has intersection types), you get something equivalent to the traditional Monad.

The project is in its infancy, so it may still change significantly, though. Look here for more detailed explanation:

https://www.slideshare.net/jdegoes/refactoring-functional-ty...

https://www.youtube.com/watch?v=OwmHgL9F_9Q

This is a similar idea to that of SemanticDB, which is used in the Scala community

https://scalameta.org/docs/semanticdb/guide.html

It is a queryable database of semantic information about the program which is generated by the compiler (compiler plugin, to be precise). Once generated, other tools which need semantic information, like linters or language servers, can consume it without having to worry about how to actually generate it.

You might enjoy a talk about it: How We Built Tools That Scale to Millions of Lines of Code by Eugene Burmako

https://www.youtube.com/watch?v=C770WpI_odM

Kythe by Google is also a similar thing: https://kythe.io/

I'm pretty sure that Roslyn doesn't do F#

We both know that "robbery" was a figure of speech, but for the sake of the discussion, I can rephrase it another way.

Whether state(s) should be in the business of "producing things" is for another debate, but it's not controversial to claim that they should be in the business of taxing things.

Now, you can go about taxation the stupid way, collecting unreasonable amount of money from the wrong people/companies for the wrong things. Or you can do it the smart way. CCCTB is the smart way.

I'm not that I'm against making money. But making money should be taxed, preferably the smart way.

This problem has a rather profound solution: Common Consolidated Corporate Tax Base

https://en.wikipedia.org/wiki/Common_Consolidated_Corporate_...

Companies should have never been taxed based on a virtual, and fundamentally nonsensical, figure as the location of their headquarters. They should be taxed based on substantial things, like (the location of) capital, labour and sales. This is what CCCTB establishes. States are still free to set the tax rate as they wish. It's just that then the companies can't escape with the turnover money to another state, essentially robbing the state where the profit was generated.

This is the most important tax legislation of this day. No other debate about taxes, like the rate itself, or harmonisation of the rates across states, makes sense before this gets implemented. The reason is that now the tax rate is evadable and only stifles local/small businesses who don't/can't cheat. Sadly, there are few states that are successfully blocking this: Netherlands, Ireland, Malta, etc. But I hope to see this one day.

https://vimeo.com/362001027 is dead :(

I did F# without having any deep knowledge of C#. I'm doing Scala without being a Java expert. It is all quite possible and a lovely experience. Moreover, the benefits that F# brings over C# and especially Scala over Java are enormous.

Would anybody here know, if there is an implementation of the Build Server Protocol around Cargo (or perhaps in a Rust-Analyzer submodule)?

https://build-server-protocol.github.io/

If not currently, is it planned?

I suggest you read a blog post What's Functional Programming All About?, written by the author of the book himself.

https://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAb...

> concurrency is still hard. Proceed with caution

> No Scalaz or any other FP-crusader stuff ever

That stuff which some people might consider FP-crusader vanity is something which can make concurrency manageable, maybe even joy.

I encourage you to open your mind, at least for a bit, and have a look at ZIO or Monix.

> Enforce coding rules with linters

Absolutely! Scalafmt and Scalafix for the win!

Because doing something like that without a type system (which Python doesn't have) to guide your hand is practically impossible.

I would expect Clojure programmers (while still functional) don't use these abstractions either.

On the other hand, typed languages, like Haskell, Scala, OCaml, F#, do employ these abstract concepts. Their type system makes these worthwhile endeavour with great payoff.

What sweeneyrod said. Scala is also OK. It has advantage over both in some aspects, but loses in other aspects. Neither of Haskell, Scala or OCaml is _the best_ -- there just isn't the perfect language. Yet! :)

Features I care about:

* Type classes: Haskell, Scala

* Module system: OCaml, Scala

* structural subtyping / row polymorphism: OCaml

* Higher-kinded types: Haskell, Scala

Other important features, but not related to the type system:

* Powerful runtime system (multicore support, green threads, ...): Haskel, Scala (kinda, with the TypeLevel libraries, but still not 1st class)

* pure functional programming focus: Haskell, Scala (kinda, with the TypeLevel libraries, but still not 1st class)

* compiling to JavaScript (so that you can use 1 language for both backend and frontend): Scala, OCaml

... maybe PureScript would tick the most boxes ¯\_(ツ)_/¯

Check out Scala! It has modern features and the tooling around it is mature.

If you like books, this should be a good intro: https://underscore.io/books/essential-scala/ (you should use IntelliJ IDEA instead of Eclipse, though)

And you can also use it for frontend development: https://www.scala-js.org/doc/sjs-for-js/es6-to-scala-part1.h... (having one language for both backend and frontend leads to great synergy)

that was a great article, quite funny too. thank you!

people are doing FP, or using ideas originating in FP without even knowing it:

* Java/C# generics

* sealed interfaces and record classes

* pattern matching

* first-class functions with closures

* even type system itself (eg Python is gaining a type system)

* ...

The world of programming languages is converging, no matter how slowly, towards ML

https://www.cs.cmu.edu/~rwh/talks/mlw13.pdf

Could somebody, who's familiar with both worlds, please compare OCaml's Multicore, Algebraic effects, Reagents with Scala's Monix or ZIO?

I'm familiar with the latter, but would love to learn more about OCaml.

> Multicore I guess I can forgive, it's not like there are any other modern GC languages that make multi-threading particularly easy (with the possible exception of Java)

Couldn't agree more, Scala with Monix/cats-effect/fs2 excels at writing highly efficient parallel and concurrent programs

> We've resorted to teaching largely Java devs Scala on the job with mixed results.

If I had to hire and teach people for Scala, I would probably go with those familiar with TypeScript or C#.

https://twitter.com/alexelcu/status/1175293360963227648

> for scala that doesn't really exist

https://nrinaudo.github.io/scala-best-practices/

it's working fine in the real world enterprise setting too ;)

> C# is holding it back though

not as much C# the language, as CLR, the runtime. Because of reified generics, which is the way things are done in the .NET world, and which the runtime needs to support, it would also require explicit support in the runtime for Higher-kinded types or Type classes. And that won't happen without C# having these features (and having them first).

F# is really really great, but it is like an unwanted child of Microsoft :(

https://github.com/fsharp/fslang-suggestions/issues/175

> not sure there are any real blockers for Scala on Android anymore. I imagine it's mostly a resource problem now

not really, it's still the problem Android being Java < 8, and Scala on Java 8 features.

https://github.com/scala-android/sbt-android/issues/334#issu...

Ian Hickson's insightful short essay about DRM was on Google+. But now it's gone...

Not entirely, actually, thanks to the Internet Archive!!!

https://web.archive.org/web/20190119000840/https://plus.goog...

I suspect that the big part of that 120MB is bootstrap-guile (Guile is a Scheme implementation)

if you want to go really minimalistic, see stage0, it's like 500 Bytes

https://github.com/oriansj/stage0

details are in the article

If you (or anybody else) haven't given up on Scala just yet, have a look at ZIO

https://github.com/zio/zio/

It's a fresh, and pragmatic too, take on how to do pure functional programming, but without advanced concepts (like higher-kinded types).

could be (and maybe even has been) ported over to other languages besides Scala

I think the author was trying to point out that Scala has type system features, like Higher-kinded types, which (although very useful in practice IMHO) are non-existent in other mainstream languages, including TypeScript.

I think that's a legitimate and, most importantly, factually correct point to make.

If you're interested in what these "Higher-kinded types" are: https://typelevel.org/blog/2016/08/21/hkts-moving-forward.ht...