akra

Risk isn't money lost, its all about uncertainity of outcomes from a finance perspective. A realized loss isn't risky; since they've changed an uncertainty into a certainty (i.e. you will lose this much).

I liked Argu when writing .NET in the past. Seemed a lot more feature rich and easier to whip something up than the free alternate C# OSS ones at the time - and IMO looking at this for a typical CLI command app probably still is. Argu's advantage over this, at least it seems to me, is there's a lot less boilerplate (more defaults, less annotations, less classes/files). You could write a solid CLI app with subcommands, etc in a single script if you wanted to. Spectre's advantage seems to be if you want to create an interactive CLI application.

Note that this effect hasn't just occurred in America but other developed countries (e.g. London, Canada, Australia) all which had more secure work, local manufacturing, local union power/membership, etc and have experienced similar trends as the US.

In our local newspaper there have been many articles about wage stagnation and the decline of our manufacturing base as well - albeit we may be a few years behind America which isn't much in the grand scheme of things.

For me this is the point that I feel isn't well argued against by GraphQL proponents. Why if I'm a Javascript developer with probably a similar learning curve I couldn't just whip up a simple stateless frontend (in Node since its the same lang) and write the query in SQL? More to the point the skills learnt by doing so are more transferable. You also give your data store a chance to be more performant (e.g. better query plans for a typical DB) using that DSL to query the data store and there's a lot less complexity (components, libraries) in your solution.

Also from what I've seen the approaches that may result in single ideal query plans in your database increase the complexity of GraphQL significantly with "GraphQL to SQL" compilers which still may not give tuned SQL especially with large graphs. Reminds me of using ORM's where often the generated SQL wasn't performant/slow. Even if it does work the complexity of your solution just increased - all for what? To translate one query language into another? There's also times where it may pay NOT to expose too much of your internal domain structure to public API's which I feel from a naive developer's perspective GraphQL could encourage (direct internal API structure to contract mappings).

It feels, at least to me, that it is another abstraction layer that solves a problem that could also be solved at the org level. If there's suddenly a use case that requires a tuned query/algorithm/index as well (happens a lot from my experience) then its easy to add as a separate endpoint and test for regression test against other endpoints/use cases supported.

There seems to be a lot of Engineering practices you need to understand and follow to use GraphQL effectively which makes me naturally suspicious of the technology. I do judge technologies for most use cases (not niche) by how easy it is to shoot yourself in the foot - the easier it is the less I rate the technology for broad usage.

The article assumes simple schemas as well - a parent with many child relationships in this article could lead to some complex resolvers. Unless I misunderstand the article many of the strategies here are in ORMs (e.g. lazy subselects) which often don't perform as well as a crafted query given the still multiple roundtrip's to the db. They also require more code, and exhibit branching which means that performance is a function of the users query. If you know your user that's fine, but then again I don't see the advantage vs a straight REST or RPC call which would result in simpler code anyhow. It seems to work IMO in cases I guess when service isn't critical, your model/schema is simple, or you prefer flexibility of data access over reliability/predictability.

Not quite. There is an advantage to being "chatty" that GraphQL proponents don't often mention IMO. You can load balance each of those join requests, cache those GET requests even if they make up only a part of the overall query, shard the storage to multiple servers, rate limit, etc. Spreading requests is usually a good thing; with HTTP/2 the overhead of those extra requests is extremely low as well. It allows sharded processing with approx equal load between nodes at the backend.

Its much easier to define SLA's and manage your traffic profile/platform when the load of each "query" is definitely quantifiable and granular - unlike a GraphQL query.

Then people come to me and say - well you can pre-can your GraphQL queries so that you know which queries are going to be run therefore you have known performance. At which point I say - why not just make a specialised REST endpoint with that query inside it?

I see it as a good backend-for-frontend adapter technology where a bulk query can be sharded into individual smaller ones using core backend services for large use-case specific views. If a query uses too much resources then the GraphQL server and/or a client ID can be rate limited by the backend servers, etc. Which is why I think its mainly a JS thing to date IMO - it doesn't solve many core problems for most backends - it solves typical front-ender dev's issues who can't/don't want to write server side code.

Resonates with some big corp's I've worked with in the past; especially in industries where technology (rather than old business models) are becoming the primary channel of sales. Technology companies with technology management often disrupt the companies managed by the old way of thinking (e.g. finance, insurance, etc).

Some of the things you mention are red flags though at least to me having worked in them before - for me they normally make me question the companies management. The biggest one seen in a previous place I worked IMO - is buy vs build as much as possible off the shelf. How many successful tech first companies who have disrupted actually use that model for their core platform? The companies I've seen get away with it until they face competitive pressure OR technology isn't their primary advantage. In fact as you get to a certain size it can make sense to build your own and reduce your vendor count + ongoing costs and take advantage of your economies of scale. How many big tech firms rewrite db's, parts, dev-ops tools or are at least open to when the advantage is there? The successful tech first companies often do, even if they were once things like book stores where it "wasn't their core business". They even open source their components often to support their business and give their tech people more cred; allowing them to attract even more tech talent. The most successful/nice to work tech places usually err to building when it concerns their platform, with some pragmatism thrown in to use modern tooling from elsewhere if required normally open source but can be bought if it offers nothing of differentiation (e.g. cloud products, databases, etc).

Cloud is just a potential enabler IMO; you still need the culture to execute. A big corporation has a lot of interacting requirements, and needs the long term flexibility to change it without being on the hook in a vendor's backlog competing with other firms. It also potentially leaks your roadmap to other competitors. Common business software (e.g. document writing, email, chat, etc) are the exception; if your a big corp your usually in a monopoly/oligopoly position - there aren't too many people doing what you do at the scale you are and most vendor solutions are really just "outsourced builds"; where the long term flexibility as the vendor pivots/changes deteriorates.

That's why I always thought analogies comparing it to physical engineering were never helpful.

Software unlike physical stuff doesn't rot/depreciate, the world instead changes around it while it stays constant. Business context and requirements change around it changes to the point where the software itself isn't as useful anymore and it has to be contorted to do something it was never designed to do over time. That's it.

In tech where things the world can move fast this is particularly true.

IMO it depends especially if your coming from C# - sometimes yes, sometimes no for existing code bases.

On the features you mention while some of those features are being added to C# (and not all of them are planned to) from what I've seen they often aren't as powerful/useful as the F# version, are not as consistent/concise due to legacy syntax or don't interact with other features as well. F# is also taking C# features so its not like you will be left behind either (e.g. Span). For me more importantly the underlying defaults are a feature that can't be ported which IMO F# wins here.

C# is a fine OO language having worked with both extensively, just F# IMO is slightly better with less ceremony than typical C# code. Is it worth switching? It depends on your problem and where your starting from. In this case they are switching from OCAml so F# probably makes more sense. If your starting from a clean state it all depends tbh what you find easier to learn - IMO many JS/Python/Go/etc programmers if trying .NET Core might find F# easier than moving to C#/Java from their own personal preferences - its often called a "typed Python" by users. For C# users probably less so; but learning it might change your C# code style for the better.

More interestingly you can also go the other way if you use only the lower level F# features (F# being mostly a superset of C# features) and a C# developer won't realise that they are calling F# code - it's all just .NET IL in the end. Did it often when creating libraries at work; it isn't like invoking another language's binary code at all. One of the pro's I guess of working with a VM (JVM/.NET) based language - interop between languages is usually much easier and so niche languages can have a much larger ecosystem than they otherwise would have.

I've done quite a bit of F# Postgres in a previous life and I didn't find it much different than other programming languages. However I tend to just use the Npgsql library directly with ADO.NET for performance which I often needed for my cases with Postgres. These days you can insert array objects, insert whole objects graphs, do batch inserts and create little helpers to read/write sets with Npgsql/PSQL directly; often much faster than using a higher level ORM. In my experience Postgres often would produce query plans that required a lot of SQL tuning/rewriting in a different way to get right (e.g. loose index scan SQL to get latest entry per group). I just wrap the solution/build with DB tests to make sure the SQL is covered well vs using the type provider. Tbh the amount of code (in lines) is mostly the same as well to do it vs a higher level framework - we did the comparison.

I thought technical analysis (as opposed to fundamental analysis) assumes markets aren't efficient and subject to things like herd behavior and other psychological effects of human decision making. Otherwise things like momentum trading wouldn't work (i.e. price would just gap to the true value if markets were indeed efficient). If tech analysis works at times for me it would show that markets aren't that efficient as a whole.

IMO markets can't be efficient because we as humans aren't - our perception of value itself can be subjective and influenced by many things including FOMO, safety in numbers perceptions, risk aversion (usually), etc etc.

But many participants are reacting to small signals only from the exchange, at least at the microseconds and smaller latencies. Real world events are not usually interpreted that fast by humans or computers; typically only market activity is. A greater danger of course when at that micro/nano scale the only information to inform trades is other market action which can cause positive/negative feedback loops between participants - for most market participants outside the HFT's and the like this could be a negative factor to the markets.

Your argument may hold for "real world" information and even then there's probably ways to even the playing field; but I'm not so sure for market information (e.g. momentum trades). Most short term trading is of the latter category except certain dates. After all information asymmetry is something that markets tend to want to reduce.

For me its all about diminishing returns IMO. The benefits of minimizing latency from a day to hours to minutes does exist but the benefit gets smaller as the window reduces (and costs more to achieve). It also depends on what you believe the purpose of the market is - to scalp and trade, or to own a piece of an asset. If your in the latter category then anything tbh lower than a second provides little social utility. I have worked for these firms in the past and while they believe they do make the market "efficient" it's really the profit motive/bonuses that drives their behavior. What they are really after is "edge" to make more profit at the end of the day IMO, and one source of edge is information asymmetry which being faster than competitors gives you.

The question I haven't really been able to get answered from GraphQL proponents is how is this any different than allowing frontend dev's to code a Node endpoint for the given task? It seems easier and more restrictive (principle of least privilege) to do so and you can ensure performance/SLI's without complex solutions only a subject matter expert on GraphQL understands. Sure you have a bunch of endpoints, but you would otherwise have a bunch of queries that have to be maintained as well. At the very least you don't have to serialise query logic to the client.

If you have a general endpoint that doesn't have performance guarantees and you need to distribute widely seems to make sense (e.g. a product you want to sell to other companies with a general query interface). I'm sure there is good use cases; but I'm not sure a general website for a company for example is one. I'm curious what the general advantage is as a "default option" for frontend dev's.

Most of those package issues also apply to C# particularly as it stabilizes towards .NET 5. However it isn't too bad once you get it; and for most standard use cases it seems to work with the dotnet cli out of the box. Many people seem to be productive with C# so I'm not sure how big of an issue it is other than the small initial learning curve but many package managers have that (IMO Maven is harder yet many people use that in Java space and not too hard once you learn it).

REPL's often have problems with package management in a number of languages as they often have a different build chain from the compiled style apps which have the chance to resolve packages. When doing .NET Core in the past I know Paket can generate these scripts for the REPL to import packages (seen csx/fsx scripts for each package) - but another comment alludes to a more supported way in the future which is good.

Doesn't seem like you have a problem with the language per se; rather the package management story for .NET Core.

IMO ASP NET Core/NET Core is actually pretty good; seems lighter weight than Java at least to me. Beats most web frameworks in terms of raw performance, comes with all bells and whistles (e.g. even Grpc is supported with a built in server) but bolted on only as required. i.e. definitely beats in performance many web frameworks today (e.g. Spring Boot, etc) with a bit more "officially supported" polish which can be important for adoption.

The problem still is the traditional .NET conservative developer culture that I've experienced in .NET jobs IMO. It stops them from trying out the best things in their space (e.g. F# as one thing that comes to mind). NET Core as a runtime on a Linux platform is actually pretty good these days. This can vary by team and company however so not a reason to not choose the technology per se.

As I've gotten older I've realised that sometimes us trying to "build our way out of things" is often just "digging the hole deeper". Technology doesn't have all the answers unfortunately; I used to think so but as I've seen more I realise I was wrong. Someone's progress is someone else's nightmare quite often; especially in a system where capital (and therefore technological control) is concentrated in the hands of the few rich.

Anything you built has inputs, outputs and waste (this is the bad stuff that makes our lives worse and is subject to the problem of the commons) - it isn't an efficient process. Often benefit accrues to the person with money, and the waste goes to everyone else. Sure there are some nice solutions out there but on the whole we probably need less building than done today; and what we do build being much more targeted to society's benefit.

As an example I look at China and think - they build a lot of stuff but I wouldn't want to live there personally with the smog, pollution, bad environment, etc. I live in a nice part of the world but can see "progress" coming close to my door. Maybe I'm just getting cynical.

But if your limiting to only a whitelist of queries what's the difference vs a standard API? You might as well then just have a REST endpoint with the query defined on the server if your only allowing certain queries. Get your Javascript dev's to write a Node service or equivalent with the query logic inside it; that way the query logic doesn't need to be replicated per client.

Would say that keeping you on the Microsoft Stack vs the ReasonML/OCAml stack would be more often an asset than a liability especially for most corporations? The .NET Core stack has a better story than OCAml in terms of popularity, library ecosystem, tooling (VS Code/Rider/VS), technology/cross-platform support and general adoption from what I can see. Fable these days is not too bad either from the guide I recently saw online in building applications with it although haven't tried it myself (https://zaid-ajaj.github.io/the-elmish-book/#/).

For me its not the code/language that is un-intelligable (all code would require me to stop and try to brain interpret it); but the fact that the article at least to me refers to too many things at once. Talking about dependency handling, using data structures with dispatch vs direct function calls, data types for errors vs exceptions, expressions, etc makes the article dense to read and hard to skim.

Many programmers have used these techniques even outside FP and would be able to understand it one concept at a time - they aren't advanced concepts to me. It's more that it isn't "easy reading"; but it seems its for an internal audience with assumed background knowledge.

I do agree that initial impressions are important for a language and "perceived" learning curve does make a difference. Things that scare people away initially do hurt adoption; things like Clojure's syntax and that it is a dynamic language on the JVM (i.e. how does that affect interop/performance/etc) all raise questions. Even if there are answers to these questions and justified reasons just like most sales pitches you've already lost a lot of people who have doubts and are already productive as they are.

As an example I remember a presentation done some time ago where the presenter was showing code in F# and many non-technical people understood the code thinking it was a pseudo code at first (i.e. business stakeholders/BA types/etc). That was a win for them. If I showed F# and Clojure code side by side to an ex-coder manager as an example syntax I'm sure would matter and they often have a say in this decision. Buy-in is an important criteria in language selection for sure, as well as current skilled developers. If the pool of devs is small how easy it is to train people and get people wanting to be trained in it thinking it may be dead end skill with no jobs? I don't have that opinion personally but some dev's definitely do. Especially because jobs in these languages are scarce; if learning curve is small then it could be used even then.

My cynicism shows marketing and perception of a tech stack are equally if not more important than other factors in tech selection in many companies. No one got fired for picking IBM or in this day and age Java?

From the features they are porting into the language I think this is the case; albeit C# will always be the more verbose language and the features will feel somewhat clunky at times IMO. Pattern matching, async yield return, async/await, etc all were in F# in some form beforehand with features like records and DU's probably being investigated as well. When I read a new C# language version announcement it does feel like I'm reading a subset of the F# feature list.

Some species of Eucalyptus I've heard need fire for their seeds to "activate"/germinate. They've also discovered a huge variety of Australian plants in valley's where the fire never reaches (think the Wollemi Pine); where everywhere else is really just eucalyptus. If fire could eventually start in an area you pretty much just have eucalyptus bush everywhere and nothing else.

My non-educated hypotheses is that eucalyptus was a very dangerous weed that uses fire to basically kill everything else around it. It managed to kill via fire every other native Australian plant in the bush expect with the exception of some safe sanctuary spots (close to water, deep valley's where moisture content is higher) many years ago. Some other plants have evolved against this and adapted to fire however (think Australian grass trees).

I don't know if it is a more accurate model of AMD64/X86 but it may be a better match for the underlying silicon (gates, logic circuits). I can see function pipelines and composition of these in some ways analogous to circuit design. After all those instruction sets in AMD64 are merely an implementation of these. Pure functions and pipelines could model circuits quite well.

I always had questions about the liquidity on offer though seeing participants flee the market in black swan events. HFT liquidity could be illusionary - its only there when its not quite required similar to how the bank "only offers you a loan when you don't need one". Of course this is exactly the point when liquidity is required; normally there's sufficient liquidity in normal times from market participants. Its easy to offer liquidity in normal times; harder to do so when no one else wants to offer it.

IMO both language types offer shared state and immutable data structures so I don't see them as mutually exclusive. As the Rust guys I've heard say "sharing state and mutation are fine, just not together". It's a question of whether the problem your trying to solve is better as a highly mutable one with "sharing" (e.g I'm thinking system programming with contended system resources) or you want to share data across many threads simultaneously and are happy with slower single threaded performance for greater multi threaded throughput (writes are rare so sharing and locking on an atomic ref on occasion is OK so you want structural sharing of data). Rust helps the coder avoid the issues when coding in the traditional "sharing and mutation" paradigm especially without a GC; languages like F# have some modern things to do this like atomic refs for data sharing, flagging mutables, async lock types, support for imperative programming etc. Both approaches work and IMO suit different kinds of problems; good to have both available.

In a previous role some time back used F# on top of ASP.NET Core. It isn't that bad and people thought the code was quite clean in the end; we had dev's thinking going back to C# even with F# using vanilla ASP.NET would be a downgrade. There's ways to mitigate the pain of the C# specific API. We went the vanilla ASP.NET Core route (for Swashbuckle) and found only the Startup class (which could be replaced by functions in hindsight) and the Controllers (which were still clean code wise) needed to be classes. The rest (majority) of the program was typical F# code with an interfaced object usually created via an F# object expression put into ASP.NET's dependency injection. Helped to separate the web controllers from the logic layer anyway and keep the ASP.NET code to a minimal. Most of the program was written in F# style with ASP.NET used just as a web server for functions basically.

There's just few public examples on how to do this cleanly so people kinda have to work it out themselves which I think could be improved.

Not quite. F# and a few other languages have had this capability for a few years now. Its effectively making the MoveNext() function on the enumerator object an async operation instead of a blocking one. This allows a foreach loop for example to wait until the next object comes without tying up the thread. Useful for things like pulling off a remote message queue, messages off a network, etc where the waiting for the next item in your "foreach" loop involves async/task based operations and you don't want to block the current thread.

If your writing a web app I've heard good things about Giraffe (https://github.com/giraffe-fsharp/Giraffe). It seems to even have a project template via the "dotnet" command to get a quick web app running. With F# I personally find Rider or VsCode better IDE's than VS as well. The workflow in F# is more like my experience with scripting languages than something heavy like Java/C#; you don't lose much by going to a more lightweight IDE and a lot can be done via CLI commands and text editing in .NET Core.