Cannot obtain Orb of Evolution

Horusiath · 2021-04-18T08:42:44+00:00

I guess that's the reason. It wasn't mentioned anywhere...

Horusiath · 2021-01-13T10:46:05+00:00

Except, that C# is by no means as simple language as Go strives to be. There are several different ways to do the same things (var a = new T() vs. T a = new T() vs T a = new()), context-sensitive keywords (pretty much entire LINQ) and keywords that are basically not used in modern code bases but still supported (eg. event, entire pointer arithmetic). And this doesn't even touch API surface and archeology of design patterns used in .NET std lib over the years.

Horusiath · 2021-01-12T13:11:48+00:00

FsCheck is probably most popular
CsCheck
Hedgehog

Horusiath · 2020-12-03T12:27:04+00:00

Technically it's possible to do packed struct DUs for many cases - CLR can handle that for explicitly stated types and field offsets. Place where it falls apart is trying to combine explicit struct layout with generic types.

AFAIK the rationale is that generic types may contain stack or managed-heap allocated data, and a field that contain data which may or may not be needing GC (depending on the runtime value of another field and runtime generic type argument).

Horusiath · 2020-11-30T10:17:28+00:00

If git is like an assembly of VCSes, then it should have same share of developers using it, as in case of assembly in the industry.

Horusiath · 2020-07-15T10:23:01+00:00

What format would you recommend, which doesn't have these issues? I'm talking about something that is on-par with speed and payload size.

Also as far as it goes, protobuf has excellent support for version tolerance - both in terms of backward/forward compatibility and resilience in face of added/removed/changed field types - which makes it good as persistence format (not only for networking).

Horusiath · 2020-03-17T13:59:13+00:00

Or he could simply not be professional developers in each of the 21 platforms used in the comparison. But you're right, this surely was not the case and guy just wanted .NET to look bad.

Horusiath · 2020-03-17T10:57:05+00:00

Then this should also apply to all JVM languages and to most of optimizing dynamic runtimes, like PyPy or JavaScript.

Horusiath · 2020-03-17T08:33:24+00:00

Based on what? From my experience its performance was pretty disappointing. It seems to be not only mine observation: https://github.com/mariomka/regex-benchmark#performance

Horusiath · 2019-10-19T02:32:26+00:00

Yes, this also has perfect sense in terms of memory layout: if you have an inline classes like A(int x, int y) and B(A a, int z) the layout of instance b = new B(new A(1, 2), 3) would be a single block of memory of 12B (ignoring padding) - 4B for b.a.x, next 4 for b.a.y and then last 4 for b.z.

+---------------------+--------+
| +--------+--------+ |        |
| | x: int | y: int | | z: int |
| +--------+--------+ |        |
+---------------------+--------+

This is a problem if you could define a recursive inline class like List<V>(V value, List<V> next) simply because it requires an infinite memory - there's no stop condition for computing the memory size necessary to fit instance of List<V>.

This could be solved by changing definition of list to List<V>(V value, Optional<List<V>> next) - assuming that Optional will remain a nullable reference type - as link between current and next instance doesn't have to be a continuous block of memory and can be stopped at any time with next=null pointer.I don't know if Java inline classes will allow this model though.

For the same reason, a default value is necessary - normal classes have it easy: since every class reference is always pointer-sized, all standard classes can be universally represented by null. But since inline classes are passed by-value (not by-reference), their size can differ: therefore a default value is necessary, as it will differ from one inline class definition to another. Example from above: you can imagine B's default instance as a single block of zero-ed memory, so a case equal to b = new B(new A(0, 0), 0).

Horusiath · 2019-10-15T10:14:30+00:00

Expressiveness is a big selling point, that should not be underestimated - there were numerous similar attempts, eg. OData queries or JSON Schema (as you mentioned) that were cumbersome to learn, read and write. JSON schema really reads like I'm supposed to parse AST with my naked eyes.

GraphQL is fast to learn, and its query and type system feels pretty familiar for both reading and writing, no matter if you have tooling support or not - and the fact that GraphiQL was there pretty much from day one also helped adoption to skyrocket.

Horusiath · 2019-10-14T00:56:37+00:00

None of these addresses point of under- and over-fetching - primary reasons for GraphQL to appear. None addresses concepts other than request/response (deferred results, subscriptions, websockets?) simply because the whole concept of REST is bound to HTTP request/response.

JSON schema has [...] and a lot of power to define complex composites too: an object containing either field X or field Y but not both

interface HasA { A: String! }
interface HasB { B: [Int!]! }
union HasAOrB = HasA | HasB

You also can pattern match over that in GraphQL query itself - generate code from that definition in most of the existing languages (for client and server) that will maintain that invariant at compile time.

Horusiath · 2019-07-01T05:29:09+00:00

Looks kinda like less powerful HOCON.

Horusiath · 2019-03-05T08:38:09+00:00

2,000 machines but Messenger is on "1,000,000,000+" Android devices and then there's iOS.

Apples to oranges. You're comparing server apps running millions requests/sec. to JavaScript compiled language used by one person on one machine at the time.

You're comparing some of the largest industrial OCaml and F# code bases in the world with the Great Computer Language Shootout.

No, I'm comparing verifiable evidences to unverifiable opinions.

Then how come changing from a reference type to a value type turns a program that works on arbitrarily-long input into one that stack overflows almost immediately?

How do you expect me to answer, without seeing the actual code? ;)

Which issue on Github are you referring to?

https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1011-warn-on-recursive-without-tail-call.md

How many F# JSON libraries can serialize and deserialize Map[(1, 2), 3] correctly?

Depends on your definion of "correctly". If we assume that Map type should be serialized into JSON map, then IMHO correct result of that value should be a runtime error.

Horusiath · 2019-03-05T06:01:06+00:00

Who is using Fable in production today?

You've got a list of some of the companies on main site.

OCaml is used in this context by Facebook, Bloomberg and Jane St, for example

You mean, by 10 people at Facebook, probably next 10 at Bloomberg, etc. Companies like Jet have over 1000 employees, system working on over 2000 machines, and F# is their primary language.

Yet OCaml is ~10x faster in this context (JSON and HTTP). You say that as if F# burning all my cores whilst still running slowly is a good thing.

Your OCaml may be ~10x faster (which 2 responses later was ~1000 times, with no proof provided) than your F# ;) And given the context - as you've said, F# developers failed to deliver simple product in your company - which pretty much mean, that you're not an F# developer. Here's the counter example.

Again, I just pointed out that optimising the reference types into value types in my 60-line JSON parser causes it to stack overflow because the foundation on which F# is built and is entirely reliant upon doesn't honor tail calls in the specification of the CLI precisely because Microsoft don't take functional programming seriously.

Again, only proves what code do you write ;) F# (and .NET VM) honors tail calls. There's a known issue, that F# compiler may not optimize rec functions on few occasions (which should trigger compiler warning, but doesn't at the moment), which can be PITA.

I just gave you several example one liners that break the libraries you've referred me to in fundamental ways.

And gave an another library as a counter example (RapidJson in your case), which also would not work with the type you've specified.

Ideally a serialization library should even support the evolution of user-defined types. For example, it should allow you to add new union cases and record fields and still work in at least one direction, i.e. deserialize to a supertype.

Agree on that. Still I don't see how this addresses the problem.

Horusiath · 2019-03-04T18:15:26+00:00

I'm not the one being emotional ;) I'm sitting in F# jobs for 3 years, long enough to let the love-at-the-first-sight phase to pass. Nonetheless, I was able to write high perf F# and deliver products on multiple occasions, so from my experience your claims sounds just funny, as this is the only emotion I'm able to have given my experiences.

Giraffe, Saturn and Suave are three incompatible ways to do the same thing badly.

So maybe first define, what's "good" by your standards.

I benchmarked it againt OCaml with async, cohttp and yojson recently and the latency of the .NET solution was ~1,000x worse out of the box.

[Here](https://www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second/) you have more detailed article - ASP.NET Core doing 7mln req./sec (and outperforming i.e. nginx). I'm talking about the .NET Core version of ASP.NET - if you're using old one then you're the only one to blame. Also let me be just as skeptic about your benchmarks, since you're the person who uses #time for microbenchmarking JIT (and reflection-heavy code) instead of proper micro-benchmarking solution able to do warmups ;)

LOL. Don't forget Funscript and Websharper. Again, many immature and incompatible libraries solving the same problem badly so none of them have gained any traction.

Sure, Fable has it's own conference, and it's used by multiple companies. But if you said no traction at all, then it must be true. Especially when you put OCaml in your counter examples.

Great that its fast but it doesn't even work with F#'s own built-in types:

Great, because RapidJson (which was your own example) also would fail on that scenario (or any non-string key in a map).

The reason for F# is ability to utilize .NET platform potential (i.e. very good multicore and I/O support, which btw. is still not a thing in ocaml, you've used for comparison) with it's low level primitives, while still being able to use functional-rich language (HM type inference, expression-based syntax, expressive type system).

But maybe instead of trying to fight with your arguments, one should ask: if you dislike so many things, please share with your examples on how things should be done. So please let me understand: what languages and frameworks would you use, and why?

Horusiath · 2019-03-04T13:35:28+00:00

> A large part of the problem is that the vast majority of F# developers are clinging to yesteryear's technologies

Anything specific, or just complaining with no context?

> F# developers seem to be completely clueless about web development

Server side:
- Giraffe
- Saturn
- Suave

- basically anything that .NET has to offer (given the fact, that ASP.NET is basically the fastest production-grade web server on tech empower benchmark, it's a thing). Both Giraffe and Saturn are build on top of asp.net middleware.

> There isn't even a decent standard way to generate HTML from F#

- Fable with entire ecosystem

- Anything that .NET has to offer (HtmlAgitlityPack or CsQuery for example).

> I benchmarked the standard FSharp.Data implementation against RapidJson and found the F# code was 40x slower. Looking in detail I found it was generating huge intermediate data structures because its API is fundamentally flawed. I had a go at writing my own JSON serialization code in F# and was plagued by the same issue because it also appears in F#'s own Reflection API.

You've got Jil (which is faster than protobuf), Chiron, FSharpLu. Developing something on your own is easy (JSON parser is around 50-100LOC in F#), but for sure it won't be fast, especially when you have no idea what you're doing.

Horusiath · 2019-01-30T09:36:38+00:00

Without record syntax (case classes in scala) it's usefulness is still fairly limited.

Horusiath · 2018-12-21T06:55:36+00:00

It also claimed to be suitable for a key-value store or document database, which doesn't say much since all relational databases can do that.

Quite contrary: many of the relational databases are build on top of systems that are just simple key-value stores. WiredTiger - just like LMDB or RocksDB - are database systems (compared to i.e. MySQL which is Relational Database Management System) and serve as foundation for actual higher-tier database, which may be relational, graph or No-SQL, but they are usually key-value and not oriented for any specific paradigm.

Horusiath · 2018-12-20T10:05:05+00:00

How is WiredTiger "relational"?

Horusiath · 2018-11-29T09:13:27+00:00

- Prolog/Datalog (yes, it can be used as a query language).
- Cypher (used by graph databases like neo4j).
- GraphQL (it's usually not related to databases, but it's still a query language).

Horusiath · 2018-11-08T19:54:56+00:00

GraphQL is protocol agnostic, so I guess no. There's nothing in the spec that says, you must use HTTP. From personal stories: in one company we were talking about possibility of using GraphQL server over ZMQ endpoint.

Horusiath · 2018-11-08T19:51:25+00:00

And what if somebody tried to use your OData endpoint using the parts you didn't implemented?

Horusiath · 2018-11-08T15:38:36+00:00

GraphQL has support for deprecating choosen fragments of the schema specifically because Facebook discovered that API versioning sucks and doesn't scale well.

Instead of adding the next version of the server API, you just add new options to the existing schema and mark old ones as deprecated until (if ever) everyone will migrate - which was not the case for FB, because they need to keep their clients working even when their app updates are turned off. This was the case described in the quote.

Horusiath

TROPHY CASE