BillyTheKing

In my (limited) experience so far with TypeSpec - it really shines in an API first approach, so you define your API before you implement it, but not so much the other way around.

It's this or writing openapi ymls... Even for people who know yml picking this up to define and write basic openapi definitions is much simpler than writing an openapi doc from hand, which is really painful

I've been using it for my latest API - I was looking for a tool that allowed me to describe APIs similarly to GraphQL and in a design-first sorta way. All these openapi editors just felt crazy clunky and made data-relationship within the API non-obvious. TypeSpec is a great tool, really helped me out here - was exactly what I was looking for!

just like everyone else - sell it on the binance p2p market for USDT with very substantial mark-ups

sooo much effort is going into saving a few milliseconds either by rendering code in the browser or on the server - honestly who actually cares.. I like react because of JSX which I prefer to just normal HTML, but whether that's rendered in the browser, or on the server, also ok to ditch the whole thing and replace it with templating.

The actually difficult problem is hardly being addressed though, namely globally distributed data stores, especially with distributed writes. That's the hard problem, I haven't really seen a very convincing solution yet for normal 'web-apps'

I mean, yes for personal accounts with a couple of thousand transactions - sure. But esp. in payments or in exchanges there can be accounts with millions of transactions a day. So you get a double-whammy - those are hot-accounts which also slow down the system, recalculating the balance for those accounts each time a transaction happens isn't an option

yes, that's the gnu cash implementation (also used by formance for example) - I don't love it tbh, yes you can add multiple postings under a single transaction, but.. if you look at one of those postings, or just the transaction in general you don't directly know which posting originates from what account, you have to sorta map it based on amounts

imo, realistically you'll end up with both for payment-operations - just recalculating balances for accounts with millions of transactions also causes issues

oh thanks a lot for sharing - I was looking for something just like this! Something like this + hurl is the perfect combination to sketch out APIs imo

I've been to Patras a few times (usually while hopping over from Italy).. I'd say, the Peloponnese is amazing. If I could just work remotely from a quiet place I would probably try and find a seaside village or so on it.

But Patras, as far as I remember it's pretty industrial, it has a large-ish port, 2 nice-ish squares, but otherwise didn't really strike me as a particularly exciting/pretty place.. Weather will be good though.

If you wanna try out something different, maybe a smaller city with a more remote vibe but with quite a bit of life nevertheless and good weather - maybe give Syros a try :) It has a beautiful old venetian town, cool restaurants/bars - some nice beaches and great nature - and all the other aegean islands with varying vibes around it! But it's also not as village-y or seasonal as the other islands - definitely can recommend!

yea, they're usually windier and therefore are (and feel) a few degrees cooler. Fortunately they aren't particularly humid either (usually) which makes them feel quite pleasant imo

I think that's spot on - what annoys me with some older Greeks is a fairly consistent 'look at our amazing history' attitude, as if they're ancestors of Gods. But then the actual culture is deeply rooted in Greek orthodoxy, driven by entirely different values, mostly pretty conservative. In reality, many older Greeks know relatively little about their own ancient history, or they focus on very specific aspects of it. Even though it's actually so colorful and full of human conflict and complexities.

I believe it's important for the country to look beyond that history. Not saying one shouldn't be inspired by it, almost everyone in the West is somewhat inspired by it anyway. This is a piece of humanity that played out on the same geographical area as modern-day Greece with a somewhat similar language, but it's long gone.

And I totally agree regarding conscription - if it were some sort of useful exercise for 6 months or so, one could probably make sense of it, but as it stands currently, it's a total waste of time.

I'm based! and have a bias!

One of the things with Greeks (in Greece) really is that they're notoriously pessimistic and depressed, unlike what people usually associate with the country. I do think though that there's a bit of a new spirit though among the younger generation which is slightly less focused on 2k year old history and a bit more realistic in the way they approach the world. But maybe that's just wishful thinking on my end

I'm half Greek, so obviously a little bias. But would love to see a more thriving tech scene in Athens. It's a cool city, with great night-life, great restaurants, and stunning places nearby, not yet super gentrified and obviously also has some archaeological sites. But it's not just 2000 years old history (yes, it's partly also pretty run-down, bureaucracy is a night-mare, etc.)

Generally speaking, it's usually sunny all year around, winters are mild, summers are hot, but one can spend those on an Aegean island..

This is a classic example of a 'contrarian' take for what feels like the sake of it. TS/JS tooling is a total and utter disaster at this point.

The commonJS/module transition is a nightmare. The fact that something like 'prisma' exists - a c-written 'query engine' that turns prisma js into sql.. wut?

This ecosystem is on a highway to hell literally.. I really hope Bun works out, because I do like Typescript, I do like programming in it - but I'm absolutely done with spending hours upon hours figuring out configs in tsconfig, jest, package.json eslintrc, prettier, vstest and whatever the next 'new' abstraction is. In Go I can just focus on the code and forget about the rest

this was a joke comment in the morning.. but actually just turned out to be an issue now. Was installing nanoid in a project using commonJS and typescript.. all jest tests suddenly failed. So I looked into jest.config - did I need to change something in terms of transpilation? or some new babbel config? some other secret flag somewhere? no, because turns out that

npm install nanoid Nano ID 5 works only with ESM projects, in tests or Node.js scripts. For CommonJS you need Nano ID 3.x (we still support it):

This whole module bit in node has been a total disaster. Incredibly frustrating

how does that work with try/catch? try/catch is significantly more verbose than just if err != nil // do something imo, and also much more brittle.

Agree re: Results type in Rust and Ocaml, etc. Those are better in my view too. And yes, you can define a Result<any> return type in Typescript as well (and in fact that's what I mostly when I write typescript and works ok) but unlike Rust this is definitely not 'idiomatic typescript/js' and other developers who might not be familiar with Result types will probably initially dislike and then probably dismiss it.

is anyone actually using Deno in production for larger projects?

$ cat helper.mjs export const sleep = (dur) => new Promise(resolve => setTimeout(resolve, dur))

  $ cat main.mjs
  import { sleep } from './helper.js'
  await sleep(1000)
  console.log("Go is great; but weird throwing node under a bus here?")

  $ node main.mjs

file://main.mjs:1 import { sleep } from './helper.js' ^^^^^ SyntaxError: Named export 'sleep' not found. The requested module './helper.js' is a CommonJS module, which may not support all module.exports as named exports. CommonJS modules can always be imported via the default export, for example using:

import pkg from './helper.js'; const { sleep } = pkg;

'What is CommonJS?'

onboarding 10 Typescript Backend developers is like onboarding 10 developers from entirely different languages. Some are _heavily_ OOP driven, and turn literally everything into a class. Some are heavy on functional programming and start using curried functions everywhere. Others are used to classic express servers, while another group has only ever worked with graphql/prisma, or has only deployed on lambda functions and hasn't really seen express-based routing.

Literally everyone comes with their own project setting, they all have to get used to that specific folder structure, or those eslint/prettier settings. And on top of error-handling in JS/TS is miles behind Go's (and that's despite Go's error handling also being clunky and not as elegant as Rust's or ocaml's, but still much much better than JS's). It is _extremely_ easy to mess up a typescript project, it's significantly harder to mess up a go project (although obviously still easily possible :)

Btw. I also don't hate typescript/JS, I think it's a great language that allows for a big variety of expressiveness in entirely different programming domains, I personally use it all the time and enjoy it. I just don't think it's a particularly great language to scale a team with.

I've been mostly writing Typescript the past 3 years - and recently started writing code in Go. Initially I was a little apprehensive, lack of array functions, slightly less flexible type-system, etc.

But after spending some time writing Go I now had to re-initialise a typescript project for a small-ish team (4-5 devs). The amount of time spent on things such as linting, selecting the correct library for server routing, the correct server, coding standards, basic error-handling and enforcing it with a custom error or Result type to get out of this nested try/catch hell which still loses the majority of errors. Setting up testing and mocking. Setting up Prisma and what not - and finally the PRs are still a hit and miss, some ok, some make use of weird JS functions..

Don't get me wrong, I really do like Typescript. But I gotta say after all of that it's just great using a language with a fantastic standard library, proper type-safety, with some coding standards built-in. It's obviously not without quirks, but it's pretty decent - and great to see that routing has now also moved into the standard library, another bit that you don't have to worry about - can't wait for some map/filter/find slice functions though!

> the cost which often gets quoted with those mistakes is not a real cost

Oh that depends entirely on the industry.. in social media maybe not, in banking and Fintech those can most certainly be real costs. And can tell you - that feels even worse

I've been in Fintechs for a bit, and this article is pretty much the result of that. As a developer (joined very early on), I wasn't initially aware of the challenges posed by settlement times. However, as we expanded, I began to see how much capital was tied up by our partners. Many times our growth was limited by our partners and their settlement times - the longer those were the more capital was bound and the less we had to actually serve demand.

Especially in a start-up's growth phase, we found that the available capital was inversely proportional to our growth. We needed more capital to manage the settlement times as we expanded, but the more we grew, the more capital was tied up, leaving us with less to fuel further growth.

In summary - I've realized that settlement times from acquirers are far more critical in Fintech than I initially thought, which inspired me to write this post. And just to clarify, I'm not a huge advocate of unregulated crypto. However, I do believe that regulated stablecoins with quicker settlement times could be really advantageous for Fintechs.

why though? this is exactly what databases have been invented for! One could simply store a mapping of numbers to their classifications as 'even' or 'odd' in an SQLite database. This approach has the added benefit of not requiring program updates whenever a number's classification changes from odd to even.

maybe it's just going to be easier to fire him in a second step once this current situation which seems to be primarily about ideology is cleared up. In D’Angelo's case it's going to be easier to just point to a clear traditional conflict of interest down the line

either that or Sam didn't tell Adam D'Angelo that they were launching a competing product in exactly the same space that poe.ai had launched one. For some context, poe had launched something similar to those custom GPTs with creator revenue sharing etc. just 4 weeks prior to dev-day

He basically re-wrote the whole software though.. which is not -2k lines of code, but + probably a few hundred a week if not more

yes, and also developers grow over time - not every company starts with 20 years of experience seasoned developers.

Lots of start-ups start with developers that have 2-3 years of experience. Once they reach the state of a rewrite those developers (if they stayed for the whole period) are probably 3-5 years more experienced than when they started and might look at things differently than at the beginning. And those years can make a huge difference especially during a start-up's growth phase

It depends a little, sometimes companies (especially start-ups) pivot quite substantially - With a Fintech that I've worked with from the beginning (which went through ups and downs, but ultimately ended up quite successful) we started issuing debit cards and pivoted to loans. At some point we just needed a different app that was properly written for the use-case that we ended up serving. It's like the parent said, the re-write was done by the same team (mostly) - those were 4 busy months but it ended up quite successful and imo it was worth it at the end. And I have to admit I was actually very critical of the re-write approach initially..