willtim

I always thought Dart/Flutter was a hedge against Oracle shutting down Java-usage on Android. Now that they have Kotlin (which devs generally much prefer over the Java-facsimile Dart) and Jetpack, I'm not sure either what relevance Dart/Flutter has to Android.

In my opinion, as a professional haskell developer, it is too hard to reason about the runtime space usage of Haskell programs to ever recommend Haskell as a "systems programming language". Haskell would be great for writing a DSL for generating such code though.

This is a noble effort and you can certainly take the moral high-ground over companies like Apple. However, often the problem is not only whether parts are replaceable but also availability of spares. For example, my 2016 X1 Carbon needs a new battery and it is easily user-replaceable, yet Lenovo no longer make or sell them. How can you make sure that parts are available, especially if your suppliers stop making them?

They ditched their own inferior custom core design and now use ARM Cortex X1.

Side-effects do not mix with lazy on-demand streams! This is unfortunately a problem with bringing functional programming constructs to a language with idiomatic pervasive mutation.

> then complain about types instead of talking about static analysis

Static types are a form of static analysis. One that is deeply integrated into the language and compiler, which gives obvious advantages such as machine-checked documentation, custom invariants and error messages (expected a Currency but got a Country), better code generation, better tooling (IDE pop-ups, fast incremental checking) etc. Other forms of static analysis are of course useful too.

I suspect they wrote thousands of lines of code "Agile" style, without nearly enough upfront design. Now there is too much code to rewrite and it's too hard to change. I would be more sympathetic if it just lacked functionality, but instead the marketing claims all these features that are likely to eat your data. IMHO, it's an example of where open-source and the "bizarre model" failed to deliver.

This is of course why garbage collected languages exist. If you don't need the performance or efficiency gained from having full control of memory, then GC'd languages will offer less cognitive load.

IMHO, programming in Rust is no harder than C++ or C. It just forces one to be explicit about lifetimes and ownership, concepts one should be carefully thinking about in other systems programming languages.

Unfortunately Rust is currently lacking structural records/structs and enums. I think they removed them early on in the design. So you'd have to name the all the types. I hope they do add them back one day.

It's better to evaluate at compile time, if possible, rather than runtime. The biggest issue with macros is code bloat, but every serious general purpose language should have them.

> Imagine the function "fn bar(x: fn(x: int) -> string)", would that be more clear with a colon?

In your example, why bother naming the inner "x" variable for the function param? It cannot be used on the right-hand-side (definition of "bar"). For that reason, the notation is not exactly "clear". In OCaml the annotation would be:

bar( x : int -> string )

That's a nice explanation of what's going on. My point remains that I found the syntax confusing though.

You are quoting me out of context. In many languages, the term and/or pattern foo(x : int) is a string, if foo : int -> string.

It did confuse me when I first saw it, but yes, it is not really a significant issue.

Well the Python community is hardly an authoritative figure on static typing :)

> That would imply that "foo(x: int)" is a string rather than a function

But foo(x : int) is a string! It literally reads "foo applied to x". In the function definition, it appears to be used as a left-hand-side pattern which is "matched". The definition is written as if to say, whenever the term foo(x) is encountered, use this definition here. At least, that was my expectation.

> Haskell doesn't use that notation either

OCaml does and Haskell once had a proposal to add it. Haskell type signatures are normally written separately, but it does support annotating patterns with the right extensions.

In Rust, a function definition left-hand-side looks like an annotated pattern, e.g.

foo(x : int)

Therefore, one would expect to annotate the return type as,

foo(x : int) : string

Since the pattern is showing foo applied to x. The Rust syntax is actually confusing for both Haskell/ML programmers (where the arrow comes from) and mainstream programmers. It's too small an issue to change now though.

Rust's support for proper "algebraic data types" is very good and gives it an advantage over languages like C++. However there are some small surprises, such as forcing all enum constructors/fields to be public (one must therefore wrap it to make an abstract data type).

Every language has its warts and these are particularly minor ones.

Rust maybe a little adhoc in places (e.g. the misappropriated Haskell/ML function syntax, enum/struct asymmetry), but overall it is a fantastic effort. It is not an easy task to combine an advanced static type-system with mainstream ergonomics, but they seemed to have pulled it off. The fact that it is also not owned and controlled by a single big tech entity is icing on the cake. I really hope it achieves even greater success.

App makers complain about Apple's dominance, yet seem to put significantly more effort into iOS apps than Android apps.

It can be difficult to avoid the culture/practices though. Every dependency you use, is code that you are ultimately responsible for. At a minimum you will need to learn how to use them; and you may need to debug and fix them. This is why it applies to other JVM languages too.

Google for "Enterprise FizzBuzz". And that one doesn't even use Spring. Yes it's a joke, but quite illustrative of why many dislike the Java culture and its ecosystem.

> Monads are not the same thing as effect types

Monads can be used to implement "effect types" and define the semantics of them. I believe this is how Koka works.

> Talking about Haskell monads just does not seem all that relevant in this context.

I respectfully disagree. Async/Await first appeared in F# as a Monad (Computational Workflow). Monads also do not necessarily have to involve closures at runtime, they can be useful just to define semantics and build type-checkers.

> I quite like it and don't see any particular problem or traps with it.

While Go's model is certainly a valid point in the design space and keeps things nice and simple, there are of course going to be many trade-offs. For example, low-level control is very much lost. There are no opportunities for custom schedulers, optimising how non-blocking calls are made, or easily dealing with blocking syscalls (or foreign libraries that call them). It would not be the right approach for Rust.

The problem is more that Rust cannot (currently) abstract over these different function types; and that they are more limited (e.g. no async methods in traits). But the idea of effects tracking is a good thing and we are bound to see more of it in modern statically-typed languages.

And why restrict oneself to just two colours? Haskell monads also allow one to abstract over the "colour", such that one can write polymorphic code that works for any colour, which I think was the main objection from the original red/blue post.

Microsoft's Koka is an example of a language that further empraces effect types and makes them easier to use: https://koka-lang.github.io/koka/doc/index.html

Whilst it may appear that concatenation of strings is easier in other (more declarative) languages, in practice, understanding the runtime performance/complexity and memory usage/lifetimes is far from trivial. Sure, a more declarative language might still be preferable, but for those who need better control and more ability to reason about how the program with execute, the Rust approach makes sense.

> Everything about these laptops feels cheap in comparison to a Mac. They are bigger, thicker, heavier, more plastic, hotter, and less elegant.

This is completely wrong. For example, a Lenovo X1 Carbon is 2.5 pounds, which is lighter than a MacBook Air at 2.8 pounds. It also offers 32GB of ram, does not have a glued-in battery, does not use glass and the keyboard is much less likely to fail. I am tempted by the M1, but from my experience Apple machines are heavier, fragile, less reliable and less user-serviceable. I also don't understand the aversion to plastics. Aluminium makes MacBooks heavy and can attenuate radio signals.

Yes I agree, the UI is a mess and they have made some bad design decisions. One time I was on train with my network connection dropping constantly and Thunderbird was giving me a model pop-up dialogue each time! It still gives pop-ups for updates. But it's open-source, relatively stable and reliable, and that counts for a lot.

The sad fact is that there is simply no money in building email clients. Email is a legacy technology and arguably no longer fit for purpose. We need a new standard and that's not something that BigTech has delivered yet.

> all of the email clients on Linux were awful

Thunderbird is pretty good and in my experience, less buggy than Apple Mail, especially when using providers other than iCloud. My wife absolutely hated Apple Mail, primarily because it would forget passwords and stop syncing/sending. So I moved her to Thunderbird and now she's happy.

This uses subtyping polymorphism not higher-kinded parametric polymorphism. If subtyping worked perfectly in all important cases, "generics" (parametric polymorphism) would not have been retrofitted to Java.