akra

There's many reasons why you would want the server, and reasons why you may not want it. Data structures and algorithms that as you scale give you an edge in the specialized problem domain you are in is usually one that I've seen. How many services have I've seen deployed that scale the DB to many cores and CPU's just to avoid some startup time? This is a problem I sadly see in a lot of Node stacks, and its easy to look good when you write a simple component to replace all that complexity and costs decrease as a result.

Most of the "serverless" things delegate to a server in the end anyway - whether they be a database, a managed service, etc. Something has to stay alive, be a server and own the state after all - serverless doesn't make the problem go away just passes the buck. For run of the mill small scale websites or websites that fit a particular paradigm lambda works fine. But it doesn't suit all apps, and its hard to make all problems fit it currently. As businesses scale custom solutions can scale better.

I would argue while it has other benefits it probably isn't as simple. Simplicity is usually the long term better choice. As the business scales since you've probably set a precedent this pattern will be copied all over the place. After enough times trying to understand who owns the data transformations, what lives where, how to support it when one part of the puzzle fails and trying to wire it all and how all these stacks couple together becomes a nightmare. Unfortunately I've experienced some of these issues coming into organizations after the original developers have left once it became too "big" of a place to work for - few people truly understand the architecture and even when they do its flaky and recovery is hard. YMMV depending on the complexity of your business and age. In the end IMO it just seems like a big workaround to keep using Node.

I've seen the same. It starts off faster and then as the business grows and features are added the problems scale up. Some symptoms I've seen on projects I've been asked to look over include but aren't limited to throwing Redis around when an in-memory structure would normally suffice because Node is too slow, scaling to 200 CPU's and using up at least 200GB gigs of RAM for a single servioce, when a 25 instances with 8 CPU's, 25GB of RAM could do the same job and cost a lot less, scared to write their own data structures/algo's that may be required as their business scales, etc.

This looks a little like inline in F# where it allows more generic method cases than standard generics do in C#/Java. Looking at the documentation I'm wondering does it allow things like - "any input type that supports the divide operator"? It's a feature I've appreciated previously when writing high performance math code on the .NET side.

Could it be because it is somewhat similar to Javascript in a way in that it is a dynamic language? Javascript while some may argue is clunky needs to be known to work on web stuff so I still have to learn it anyway. From what I've seen expressing concise patterns isn't where the weakness of modern Javascript is, and therefore I'm not sure if adding Clojure makes it that much better. It doesn't necessarily address the weaknesses that slow me down when working with Javascript is what I'm getting from your comment.

REPL development is great, but I'm more keen to try it on something like F#'s Fable, where I get static typing, the REPL driven development experience (F# also has an adequate REPL with package manager support), with a concise language that maps pretty closely to Javascript. At least then I'm covering up the weaknesses in development I see when doing Javascript - the lack of a type system especially as the project scales. If I'm going to use something to better my Javascript it needs to add something that Javascript doesn't have to make up for the extra complexity IMO. My biggest frustration when writing Javascript is remembering what each function returns especially cross libraries/cross projects. At least for me I'm not sure how ClojureScript fixes that problem. Especially since I could use something like Lodash to get the standard FP functions/syntax.

In the past I found this tip to be helpful: https://wiki.postgresql.org/wiki/Loose_indexscan. You can emulate it but it would be good for distinct to do this natively for default fast performance (distinct key queries) to avoid needing to know these tricks of the trade.

From what I've experienced code based frameworks are often used because the language itself doesn't handle that case well on its own. In the case of F#, JS, etc, using DI again as an example, partial completion/currying once you get your head around it means that quite often programs are just chained one line factories (similar to the one line you used to register your singleton/instance in a DI framework so no more code bloat). As a bonus you learn something that is multi applicable, not just for DI and doesn't bring in any more "magic" or runtime errors if a registration is missing because the compiler catches it. Everything is just functions/modules which means mocking is a breeze too, refactoring is easier, etc.

This is my own personal experience here mentoring dev's in both technologies, especially when they come from different backgrounds. YMMV.

I'm just stating the experience I had, and the observations I encountered in that job that formed that opinion. To clarify I'm talking about a beginner that needs to be productive quite quickly to earn their paycheck so their code has to somewhat scale to a medium sized solution and get accepted by a senior dev in a PR process. If they aren't beginner concepts as you state why are they in most "Getting Started" templates and their use is mandatory? As an example many of the common app types use a DI framework straight away following its own standard (e.g. ASP.NET, Spectre.Console, etc) and while an experienced person picks this up quickly someone new to the language from what I've seen struggles. These are concepts I had to explain to a beginner I had to mentor at the time pretty quickly.

Most F# code bases I've seen that make it to prod don't use frameworks for those concepts even as they scale; basic functional patterns seem to scale up to reasonable sized solutions. If they do use mocking/di/etc its only to make the code more C# consumable at the edge for some other C# framework they are required to use. I'm not talking about toy projects here. My point was more that at some point with C# you will need to learn these things quite quickly even for basic use cases or find yourself writing clunky boilerplate (which most new developers will default to - the you don't know what you don't know problem). However with some other languages you may never need to until much later in the learning cycle - I was working for a very successful large business that built the whole stack without ever using some of these things. If you want to encourage people onto your platform these are some of the people you need to win.

IMO It just seemed the standard to get nice code that was prod ready in F#, even JS or Go, doesn't require as much learning's as a C# app. It's not just a C# problem mind you but from what I've experienced first hand it has scared developers away.

Anecdotally when I've had to show developers how to start with .NET Core the problem isn't the SDK (install dot.net at the website) or which template to use (i.e. just tell them to pick that one) its C#. This is especially true if they come from a JS, Python or Go background. I say this as someone who does doesn't mind C# and thinks its pretty capable once the learning curve has passed.

At one stage I had a JS developer just try the F# template instead and the difference was stark. Explained to them Async F# - Promise JS, Module F# - Module JS, showed them a unit test example and they were writing production code in two weeks to a month. It made me realise that over the years there is a lot of knowledge I just take for granted that many beginners just don't have especially now when there are much friendlier languages for beginners. Things like dependency injection, how it resolves based on types, and which framework to use and why, mocking framework choice (vs simple stub functions), can only mock interfaces and why, the class structure and how you should group functions into appropriate classes, abstract classes vs interface default methods, LINQ vs OO style coding, nullability annotations all over the place, OO design patterns, the need for Resharper or equivalent unless you can write C# syntax from scratch, the list goes on and on. With most C# apps there is a lot of knowledge assumed and baked in which can be daunting for a newcomer. C# is not alone here I understand that - the same thing can be said for other languages too. But it has made it harder than it needs to be especially when it is actually a good platform but C# scares many developers away especially as it adds more and more features on top.

Litmus test for a language to me: Does it need an IDE and tooling to be productive in? The more tooling it needs the more complex IMO the underlying language is in syntax and complexity. Complicated refactoring tools? If so its probably too complex for a beginner especially now that the language space has quite a bit of competition. As an example watching a developer do this in a previous role in F# you just create a new file and cut and paste the functions around; in C# the dev's I've had usually resort to Resharper and a full blown IDE to extract variables/methods, do code generation, and basic refactorings unless they want a lot of manual work.

In my experience from what I've seen there are ways to use natural keys and handle domain changes - I've seen some systems like this work quite successfully. The cost to using synthetic IDs (auto-increment, UUIDs) is a lack of reproducibility and slower importing of data especially across multiple tables/entities limiting scalability. This can be very problematic for certain classes of applications I've seen, but not most. While I agree with your comment for many classes of apps as always there is no general "silver bullet" answer - it depends on your problem space.

Some cases I've seen in previous roles where some natural key is required include reconciling third party data sources, or processing events from a topic or stream and being able to replay the event log, etc knowing that a different ID may break other third parties you don't control since they've already imported the ID. Being able to replay your data sets from scratch and get exactly the same data can have some real advantages for some apps.

Of course you need to be aware of the domain and assume that the key can change over time and have strategies to deal with that (e.g. entity version tables bound by time, data migration to add key attributes, etc etc) and the data structures/processes needs to be designed for this. There's more work in it for sure to get right - it shouldn't be the default. But in some cases I've seen it work really well which frankly surprised me at the time.

But of course on a Win/Linux system you rarely need to use three fingers at once. On mac this is all too common for even the basic tasks you state.

Shift + End: Select to the end of the line Home + End: Select to the beginning of the line Home or End: Move to beginning or end of line respectively.

What's worse is when I plug in a keyboard with Home and End buttons on a recent Macbook Pro they still don't work. Do I need another plugin for that? Even if I do personally I don't find the Mac keyboard shortcuts better than Linux/Windows. Tbh after using Mac for 2 years running now every day at work I still don't quite get how people find it easier - I still wish personally for a Linux or even Windows machine to speed up my productivity.

And that's because people prefer what they are familiar with them - the mental leap to jump to another way of working for most people isn't pleasant and isn't really worth the investment. Mac still feels like a "second language" to me just as Linux must feel to mac users - I'm always translating it back to "how do I do this Linux/Windows thing" in Mac. In the end Linux, Windows, and Mac are perfectly capable OS'es and the differences is marginal between them which makes switching difficult. But I do prefer my Linux machine these days - more just comes out of the box.

Will try it out. Having said that it is on my Linux machine "for free". I'm not even quite sure if I'm allowed to use these paid apps on the Macbook Pro I've been given.

People state consistent shortcut mapping is an advantage of using Mac but after 2 years of being required to use a Macbook Pro I'm not really sure about that - often they are more complicated IMO. I still miss built in Linux and Windows key mappings. For example Windows + Left to move the window on the left side of screen for side by side apps on the same screen. Great for remote demo's and coding sessions. Ctrl + Shift + F4 to take a screen shot vs Linux PrtSc feels backwards at least to me. On the mouse pointer side with scroll direction most people I know also get a plugin to swap the scroll direction when they use their mouse and switch back to track pad. Another example - on VS Code very often the key bindings don't work on my Mac whereas on my Linux machine they work every time. My point is while I'm probably don't know all the tricks to learn since its not my platform of choice YMMV.

I think the impression of "better key bindings" comes down to familiarity more than anything. Getting used to something else seems uncertain (it may never be as good despite learning investment) when you know on the other platform you can just "get things done fast".

C#, or more specifically the .NET VM (goes for F# and VB too) has a lot more features that make it a lot easier to avoid GC events than in the past. Managing memory especially across interop with Span support means a lot less copying from managed to unmanaged memory as an example which would help a lot with games that often need to invoke operating system libs/drivers.

There's been times where I've had to spend quite a bit of time trying to change the SQL in subtle ways to get an index to be used and do the join algorithm type I wanted; when it didn't want to do so. Usually improved performance by a massive factor for the datasets I was working with (e.g. 10x). The predictable performance as well was a big factor - I would prefer predictable and adequate performance over peak performance but high variability every time.

In the end after all this frustration I wished I could have written the query plan directly, especially when I used Postgres with no query hints. And yes I'm aware of Postgres and all the tricks that you can do to make it do certain types of joins and such and I employed many of them (adding statistics, loose index scans, all the index types and others). IMO the potential this could open up is quite large given many databases all have the indexes/algorithms and many data structure types these days. Gluing them together in a performant way where you use the appropriate algorithm/data structure index for the data on tables/JSON blobs/etc seems to be the hard part right now that requires a lot of trial and error and learnings of the SQL optimizer to get right.

I've seen it work in reverse when the systems are just "too hard" to change. Think old legacy systems with large monolithic mainframe architectures as an example. Because it costs too much money to change them and the business needs to keep running many restructures just fail and managers just keep dropping.

I see Conway's law as an equals relationship IMHO, not a cause. The side that can give ends up adapting to the side that can't. In newer business where the architecture isn't established of course the structure influences the design. As the architecture matures and is worth a lot of money to replace it sometimes switches the other way. This of course can kill a lot of big corp's and IMO one of the biggest reason they may seem less agile to startup dev's - they have so many use cases to handle and systems have grown so complex it is a lot of effort to understand yet alone modernize these architectures. Often as well because they have been successful for awhile the regulators/governments have caught up with them and they have obligations that aren't so easily depreciated in any replacement.

Would be extremely worried about counterparty risk though. The other guy has to pay up and I'm not sure of the controls/regulations around enforcing that?

While this may be true, there's no point comparing yourself to other countries if you did achieve success, and are slowly losing it. The article makes the point that previous generations did have that success and slowly for newer generations it is being lost. That's a failure that needs to be highlighted - in the end against previous generations livings standards if you agree with this article we do not currently measure up to those standards.

IMHO I think globalization is to blame for this; it has transferred equity/ownership from Western countries over time. It has given us cheaper electronics, cheap aviation/holidays, and other discretionaries but in return has denied people of the essentials (cheap houses, job security, etc) and has transferred existing wealth away. The rich have the means to protect themselves and even profit from this redistribution of wealth; it's the middle class instead where much of the wealth was has slowly been drained. Instead of wealth they now substituted it with debt to keep the system running.

In the country I live in house prices are highly proportional to debt growth, much accrued to foreign debt. Our exchange rate stays high since issuing debt in the local currency despite increasing the CAD and draining wealth bids up the currency on the FX market. As long as houses don't crash (which is where most debt is issued) the dollar's worth doesn't deteriorate and we don't see the drain of wealth. As long as debt growth keeps growing we always create positive pressure on our exchange rate. The sad part about this of course is while young people can't afford houses, the goods they may substitute for this (cars, holidays, gadgets) are all underpinned by the debt used to bid those houses higher via a higher than otherwise FX rate.

A framework that you can stay high level if you want and optimise when the rare but exceptional case arises on a particular route without splitting the process/resorting to C++ interop (with its own performance issues), or the risk of needing to rewrite due to performance to me is the big selling point. In a previous life I got some significant latency benefits by doing just that. I think its probably only gotten better with .NET 5.

Depends on your use case. I've written quite a few backends that didn't use a database and there are a number of cases for the pure HTTP benchmark. Pass through proxies with injected behaviour, in memory key-value data storage APIs, memory mapped files, etc. IMO not every shop offloads the state to its DB. Once you add the database you are really testing the DB driver - and that adds a lot more variance to the test. Maybe its just the DB driver for that particular DB?

A fast "Hello World" benchmark implies that the HTTP/transport layers of the framework are very fast. That's your base and the lower bound to your best performance potential. As a real world example if .NET ASP NET Core has the best request/response benchmark and its better than say nginx (a popular reverse proxy) it might be better to have all your gateways using a reverse proxy implemented with that as its base instead. Over your whole network depending on your scale that could be a big cost and latency saving measure. I wouldn't be surprised if Microsoft or it's community have started writing one.

This. There is a wide wealth inequality gap and a lot of excess savings that even at close to zero interest rates people don't know how to invest it. IMO this says a lot about our technological progress rate; which despite what many here might believe has been declining and bar a few outliers has been mostly evolutionary barely keeping pace with the world's increased population growth.

Its like the low hanging fruit of engineering has been picked, or we are waiting for the next big technological breakthrough to come about. I look at even the lifestyle 30-40 years ago, and despite more efficient engines in cars (which isn't a problem with cheaper fuel anyway), the mobile phone and the internet (which isn't all good news IMO) not much has changed lifestyle wise. In some measures such as food prices, house prices, deep social connections, and other more base needs its gotten worse for the average middle class worker in a typical Western country.

IMO it feels like we've hit a stagnation which is reflected in investor preference to hoard value.

Gold's differentiator is long term trust. No matter what other people in the world do it will always exist as it is as long as it isn't touched.

With gold I trust the laws of physics and reality (not a human based system), with BTC I trust the consensus of the network participants and that the rules everyone follows will result in trustworthy outcomes, with a bank I trust that bank.

The big threat to BTC trust therefore IMO is if the network participants as a whole or enough of them aren't trustworthy. Marginal cost of mining a block favors cheap electricity countries (i.e. hydro China power) in the long term as the difficulty of the network changes to price out other competitors as they scale up. In that instance do you trust the person with the cheapest electricity to verify your transactions? Given my understanding of crypto that's probably the biggest threat to any long term investment in BTC. For PoS currencies I'm guessing your trusting the stakers by amount put down (i.e the rich people) to verify your transactions.

They could and can. The problem with both PoW and PoS is concentration of consensus/trust over time I think. There are models I've seen that break that up somewhat in PoW and potentially other forms by relying on something that is hard to concentrate (e.g. the market for consumer grade CPU's, social networks, etc). I would like something that anyone can run, but has some natural barrier that prevents it from being centralised.

The thing is for me, and maybe that's an opinion, is that the investment vehicle due to scarcity is the more important utility right now. Given all the QE and low interest rates across the board worldwide that is the real value prop. There is a need for an asset such as this to preserve wealth, and other assets such as gold have market mechanisms to stop them running away too far I think (e.g. gold certificates, reserve banks willing to liquidate, etc).

In first world countries for most people I would argue for all its faults the banking system is "good enough". In my local country can send money to people almost real time and pay by card quickly and easily without fees. Sure there is still room for improvement, but for most average people the need to change is low. Especially when I still need the banking system as "primary" to pay my taxes, settle my bills, etc - you know all the "real stuff".

While I think it would increase the popularity of F# for sure I'm not sure that from a performance perspective this would be a good thing. Refied generics (as opposed to type erasure) as an example is leveraged heavily in F# for partial application, and IMO .NET has more room these days to get good performance than the JVM if you put in more effort into it (e.g. Span support, Struct Types with no boxing, full generics support at the JIT level, etc). F# is designed to use these features - the .NET runtime even built some of those features to enable F# (generics) from what I understand.

"partially applied functions to other functions" - In C# you do this anyway via Fluent interfaces and/or lambda Func<_> arguments. The only difference is in F# any function can be made into a fluent style pipeline (|> operator) due to this partial application whereas in C# the function has to be built specifically for it. Partial application for me is one of the reasons F# code tends to be nicer than C#/Java code there's less need for things like DI containers, and other big frameworks each with their own learning curve and corner cases. It feels more like I'm coding in a static version of JS/Python once you get used to it vs C#/Java which have a lot of ceremony - expect that type inference you mention means those partially completed functions are much less likely to be used wrong.

As one of the clueless novices on this topic what I fail to understand is that proof-of-stake and other consensus mechanisms have been available for alt-coins now for a little while - yet BTC is still dominant. Is it just because of popularity of BTC? If so I struggle to understand how the market is rational here (not saying it has to be). And do other coins/forks issued with similar rules/characteristics cause a price decrease in BTC due to fungibility? The confusion you speak of may come because people see BTC as the successful coin and see other alternatives may have weaknesses that "are priced in". As a novice, because I assume there's no free lunch, other currencies not using PoW could have weaknesses that BTC does not have hence the price. For better or worse the most successful coin determines what people see as the successful approach to crypto at the time.

To your point I've also seen that some coins may still prefer PoW, and may have mitigated many of the disadvantages of it (e.g. made it harder to centralise mining).

"Too big to fail" - and that's how you increase the supply of BTC without actually doing so I think.

As long as an entity (such as the government) prints money and takes the hit on the spread people will see contracts of BTC as equivalent as BTC w.r.t value. Its basically banking, but since fiat is still the prime currency of legal settlement (not BTC) no one will think its possible to "run the bank" as that entity in the event of a run will pay the difference. BTC is not actually required to settle anything by most countries laws, so actually delivery of BTC isn't guaranteed. This does undermine actual BTC especially if actual BTC is harder to spend - the pseduo-BTC would then have more utility.

In other words BTC could be the same as fiat potentially in the longer term. It will be more transparent of course since it it easier to take delivery of than say gold (or cash but less so), but as long as they don't give you that option in your product that's fine. Even cash is like this with withdrawal limits, and other laws. If fiat was only valued by the actual cash in the economy it would be worth a lot more than it is now btw.

Agree that you want those things too. But when you are choosing between two different frameworks of similar maturity and you have to choose a tech stack it can tip the decision somewhat, especially if you don't have the time to POC a stack and you need to make a decision.

An example scenario could be if a company has a choice between Java (Spring) and .NET (ASP.NET Core). Both are quite popular, have documentation, a big ecosystem around them, etc as you mentioned. If you might need to do low level/advanced web code at any stage the plaintext benchmarks may sway them to use .NET over Java; all else being equal. In that benchmark ASP.NET Core trumps Spring by a very large factor (Spring's 2% vs AspCore's 100%); you then obviously look into the benchmark to compare and contrast as you shouldn't trust them at face value. Although having said that if the .NET one is better tailored than the Spring one it does send a signal that the .NET one has a more performance orientated community willing to maintain the benchmark which IMO is a positive still.

I do think it depends where you live and what ecosystem's are around there. F# to me fills a niche - i.e. in an ecosystem that uses .NET but is also more tech-savvy and willing to evaluate best tools and new approaches. That intersection of users being small shows a bit about .NET developers culture than the F# language itself (IMO only!). It happens less in the Java ecosystem and I suspect that's because Java was much slower to improve - C# isn't the best language on the platform IMO but it is improving all the time. Often reading a new C# release notes in previous roles (C# 6, 7, 9, 9) felt like reading very old F# release notes which means people don't necessarily have to take the risk to get the language endorsed in their enterprise - they just need to wait and they will eventually get something representing it (if not as generic or ideal as the F# impl).

That's more an observation I've seen on the ground in previous roles but YMMV.