This is why I love Go. Nobody was asking for this, but they took the time to do it right and continue to Push go as a memory safe, high-level systems language.
It's been discussed for a long time, and the related proposals were heavily upvoted, including various older proposals.
As I understand it, part of the reason it took a while is that the core Go team was generally of the opinion that doing user-facing SIMD APIs the right way was to design a high-level, cross-platform API that would stand the test of time, and that was then punted a few times given its complexity and need to do other things.
Part of what helped the current approach take off was switching to a philosophy of designing a lower-level architecture-dependent API first (the 'simd/archsimd' package), and then later doing a higher-level portable API (the 'simd' package, which is topic of this blog post).
That two-level approach I think also gave some additional freedom for the design and implementation of the friendlier / high-level 'simd' package, including because the lower-level 'simd/archsimd' package is available for people who need or want to drop down.
This is kind of the opposite of Go. Not giving people what they are asking for.
There are pros and cons of course. You don't have 17 different ways to iterate over an array, so that's nice. But you also went 13 years without generics, despite them being one of the most requested features, because the designers didn't want that complexity inside Go.
Overall I think Go is better for this philosophy but there are times where the language is clearly written more for its maintainers than it's users.
Go shipped with generics (aka bounded parametric polymorphism), but only for built-in types: slices, arrays, and maps. That, with subtyping via interfaces, handled most demand for generics. The most common pain point was custom containers.
Go was first released in November 2009. Russ Cox posted "The Generic Dilemma" [1] in December 2009. The comments show the generics debate raging from the earliest days.
As a fun side note, I forgot I posted a comment on that post pointing to Ada's generics. I was in college, and Ada was our intro language.
> the designers didn't want that complexity inside Go.
Yes, with some nuance. Go's goal of writing server programs didn't require the type-system complexity and run-time hit of user-defined generics. [2]
> Go was intended as a language for writing server programs [...] Polymorphic programming did not seem essential [...] so was initially left out for simplicity.
>
> Generics are convenient but they come at a cost in complexity in the type system and run-time. It took a while to develop a design that we believe gives value proportionate to the complexity.
Some of the concerns around generics and why it took so long were for the users as well. One of the biggest draws to Go has always been that you get the performance of a compiled language and yet compile times are so low that it can feel like you're developing with an interpreted language. The design of generics needed to maintain the compile time advantage or else it wouldn't feel like Go any more.
Languages like CLU, Ada, Delphi, Standard ML, OCaml, D, were having Go like fast compilation times, with generics, some of them decades before Go was created on much weaker hardware.
That's not what "memory safe" means. "Memory safe" is a term of art meaning "not susceptible to memory corruption exploits", like stack and heap overflows, UAFs, and type confusion. Last I checked, there are essentially no non-contrived memory corruption exploits for Go programs; the best you get are people demonstrating register control on contrived programs.
The definition I'm giving is the same as the ISRG's definition at MemorySafety.org. It's the thing everybody is talking about when they talk about memory safety.
The claim being made here is "big if true", because it would imply a lot more languages than Go "aren't memory safe", despite decades without memory corruption exploits.
The exploits aren't the only issue; they just get a lot of air time.
It's remarkably easy to segfault Go applications with data races. Any object with multiple words (so a slice that's an array pointer, a size, and a capacity. Or a fat pointer with the object pointer and the vtable pointer), can be read in an inconsistent state from two threads which can cause out of bounds reads and writes. And this comes up all the time with how heavily the language encourages concurrency.
It's just difficult to actually exploit because of other considerations that practically add a lot of runtime entropy.
They aren't the only issue in programming language theory, but they are the only issue in the ordinary context in which we discuss "memory safety", such that if someone not in a PLT forum says "is Go memory-safe" and you say "no" you will look a little batty.
The was for a time a vogue for "zero trust networking" and I'm fond of pointing out that the same thing happened there: people would come up with their own axiomatic derivation of what "zero trust" meant, but in reality it was a term of art meaning "non-Google implementations of BeyondCorp".
Terms of art are kryptonite for message board nerds.
No, it has real world implications. I worked at a heavy go shop; every time we'd have a new batch of hiring, the segfault bugs would start rolling in from these memory unsafety issues. The data race detector was good, but not perfect. Yes, those new devs would look at you batty until they saw the bug reports roll in.
And yeah, we tend to use the PLT definitions when we're talking about literal semantics of programming languages. Nothing in this thread mandates a security focused sub-definition.
And even Rob Pike described Go as "not purely memory safe", in a slide that obviously references this exact data race behavior. https://go.dev/talks/2012/splash.slide#49 They considered this a practical tradeoff for simplicity versus the major managed languages defining what happens during data races in a way that doesn't allow you to break memory safety.
Again: I am not disputing that there are correctness issues that come from having Go's concurrency and memory model, just like there are in (the large majority of) other languages with similar models. But those issues are not security problems, and security is what we're talking about when we talk about memory safety.
I feel like you're coming from the sort of constrained view you're accusing others of.
Iny experience, the ultra security focused view isn't what most people think of when they hear memory safety. It's one aspect, but one among many. For instance debugability is much nicer when you can't break the object model and get a nice trace out of the system versus when you're trying to find memory corruption with gdb or something.
That said, even the ISRG definitions I've found don't list protection from exploits. It does include out of bounds memory accesses in what makes a memory unsafe language, which would discount Go. Yes, they explicitly list Go as a memory safe language, but there's a good chance that they simply don't know about this behavior.
As someone who used to freelance in exploit research, the go behavior doesn't seem insurmountable for finding an exploit on its own. Frankly it's all the other ecosystem stuff that makes it harder. The fact that go code has a habit of being deployed multiple times a day, you a lot of times don't have access to the binaries, there's generally no dynamic (on Linux) so you have no relatively stable code to find gadgets in, etc. (Although there are aspects of the language like the relative simplicity of the compiler that do help you in some of those regards).
You comment on this subject regularly in this way, but opinions do vary. Rob Pike says Go is not purely memory safe under concurrency. I as someone who has written multiple languages would describe it as "memory safe except for a pointer-skew hole undermining concurrency" or maybe say "race-free Go is memory-safe".
Seeing a correctness issue that makes Go not memory safe in some circumstances warrants questioning whether it is memory safe. On balance, you might say it is, but to constantly tell people they are wrong for saying otherwise is policing a shared term.
Go’s issue isn’t data race, it is tearing and corruption. Pretending it is on the same class as what is considered data race is again, basic software engineering.
Java arrays are thin pointers to Array objects, which contain the length and data in the same place (on the far side of the pointer). Since thin pointers cannot tear and Array objects cannot be resized, Arrays themselves are always memory-safe in safe code.
Go slices are fat pointers to undecorated memory. The slice itself is a 3-tuple of pointer, length, and capacity. If you append to a slice that's already at capacity, the Go runtime will allocate new memory for you and return a new 3-tuple. If you assign that result to a variable that's also being accessed by another goroutine, the latter can observe the slice in an inconsistent state. It can, for example, see the old pointer but with the new length, allowing out-of-bounds access. None of this requires unsafe code.
The same issue applies to string and interface variables, which are also fat pointers.
Shared Go slices are a bad mix in concurrent code. This is a given. But its also not a fair comparison, you should instead compare java arrays to go arrays, not slices.
This goes for slices, strings and maps. Those a usually wrapped in a mutex, or used with sync primitives like sync.Map.
The exact equivalences between the two languages are not the point, and anyway, Go arrays are fixed-size and have no Java equivalent.
The point is that Java does not have this problem in the language or the standard library. Of course, you should not write racy Go code; the language provides ample ways to avoid the race, such as channels; and the race detector will generally find such racy code, provided you turn it on. However, the issue is that this race leads to memory-safety violations; it can occur especially in code written by novice Go programmers, and it's well acknowledged by the language authors [1].
> Those a usually wrapped in a mutex, or used with sync primitives like sync.Map.
The same can be said of C or C++ constructs (and many "anti-Rust" people have historically said that) -- the point is that their use is not enforced by the language and so bugs can lead to panics.
I write a fair amount of Go and Rust so I really don't think either language's flaws are fatal, but it comes off as weirdly defensive to redefine memory and data safety to be "well if you use it properly it's safe". It's totally fine to say this is a problem the Go language did not find important enough to require compile time enforcement and so solving it is done by convention and testing with the race detector (which a similar answer C and C++ give to this problem).
From what I understand a data race on a simple built in feature like an interface pointer can result in a bad address / type pair, which can cause memory safety issues on any future access. I don't think you can get the JVM itself confused about what type a pointer points to.
There is no memory safety without freedom from data races. One is a prerequisite of the other. This is why languages like C# throw exceptions on unsynchronized concurrent access to some container types, and treat all property accesses as atomic.
> I have never seen real Go code (i.e. not code written purposefully to be exploitable) that was exploitable due to a data race.
And from tptacek in that same discussion [2]:
> The fact is that Go doesn't admit memory corruption vulnerabilities, and the way you know that is the fact that there are practically zero exploits for memory corruption vulnerabilities targeting pure Go programs, despite the popularity of the language.
I am, but you’d be surprised. All of the single-threaded languages are fine, for example. Very few languages are actually low-level enough to allow data races. C# and Java go to great lengths to avoid it.
Race conditions in general are another matter, and aren’t generally considered a requirement (though you can certainly create nasty bugs).
The claim is not there is no data races in Java programs. The claim is that Java programs are memory safe, because the underlying virtual machine memory model is free of data races.
Go does not have that.
(Of course also Java may suffer from memory safety issues on system boundaries to unsafe code and due to JVM bugs.)
I suppose that if you create a map in one thread, and then access it from another thread, then that might cause segmentation faults? Because map is a type that is implemented in C.
(The gist: memory safety is a term of art coined by security practitioners. Go, Python, Rust, Java, others: memory safe. C/C++: memory unsafe. Periodically, people in different slices of industry or academia come up with new definitions of memory safety that declare Rust or Go or other languages to be memory unsafe, but that is not by the broadly accepted definition across industry.)
I define undefined behaviour as a bug in C++. Now C++ is memory-safe!
btw, it's not actually that hard to write correct code in C++, easier than in C because you have all the container types. The problem is that nothing will tell you when you write incorrect code - there's no guarantee.
UB is part of the C++ standard. Surely you can understand the difference between the C++ standard and bugs in compilers implementing the C++ standard. This is that.
Rust does not have an ISO standard, but it does have a language design, and if you knew the first thing about cve-rs (including what’s on its own Github page), you would know that this is an extremely confirmed soundness bug.
The cve-rs repo is not meant to be the toxic gotcha aimed at Rust language maintainers you seem to think it is. It’s a repro case.
> I define undefined behaviour as a bug in C++. Now C++ is memory-safe!
I mean, sure, insofar as such a thing would also imply that a) the standard would need quite a bit of cleanup/clarification work to not contradict your definition, and b) the main optimizing C++ compilers are miscompiling code, analogous to how cve-rs is a rustc miscompilation rather than an issue with Rust itself.
(Fil-C might be an interesting exception here, though IIRC its definition of memory safety is slightly different)
Since we are not at some point in the future where that correct compiler exists and there is only one official compiler, the distinction you make is practically meaningless!
I mean… no? It matters whether something is a part of the language or not, because it matters if you can write code relying on this behavior. Since this is a compiler bug, you cannot - the code will stop compiling the moment the bug is fixed.
There are no known instances of this bug being encountered in the wild, and if you look into it, you will see how extremely unlikely such code is.
> Isn't ten years enough to call something a feature of the language rather than a bug?
I suppose it depends on who is doing the classifying? From the developer's standpoint I'd imagine intent is all that matters: a bug is something that does not match developer intent and that is (eventually) expected to be changed to match the intent, while a feature is something that does match developer intent regardless of how old/new it is. From a user's standpoint I'd imagine it's a combination of developer intent and the user's reliance on said behavior, but IIRC in this particular case there's no known non-demo code that has organically run into this particular bug so there's little weight in favor of calling the bug a feature despite the devs' stance.
Also as GP said I think one needs to be careful to distinguish between the compiler and the language. IIRC the devs have known for basically this entire time exactly in what manner the Rust compiler fail to implement the rules of Rust the language, but a general fix has been blocked on long-running projects that have only recently been approaching the finish line [1].
Well, you're right about one thing: the fact that I've spent my career in software security doesn't make me "broad consideration". The cites I give on what "memory safe" means, though, do.
My argument has never been "memory safe means what I say it does because I say so", but I get how that's a much more convenient argument to knock down than the ISRG site built specifically to talk about this.
ISRG is wrong too, definition-wise. Go is not memory safe. It is much safer, and I wouldn’t fault you for taking a C codebase and porting it to Go to avoid memory safety problems, but that does not make it memory safe in the same way Rust et al are memory safe. This is the same way that MTE does not thwart all memory corruption but it stops a lot of them. I accept your premise that Go has brought memory safety over the line to where it is apparently easier to find logic bugs than exploit memory corruption, which is laudable since C(++) has never been able to do this and likely never will, but in line with the pedantry that started this whole chain of comments, it’s not memory safe.
You can write unsafe code in Go (import unsafe), but then, you can do the same in Rust. Unsafe code is not the default, and in day to day Go i rarely see the use of the unsafe package.
What he probably means is data-races in go can result in memory/type unsafe accesses -- I suspect, likely due to slice types -- not sure if that is true/false.
Sure, but a data race is, IMHO not the same as memory safety. A data race, can be 100% memory safe, but just cause a logic bug in some program. I often see people mixing memory safety with racing. Go has bounds checks so you end up with a panic either way. Not UB.
As an (outside go) example, Ocaml (5) promises strong memory safety, but not to be data race free. A data race is not something we can prevent, because its usually not bound by code, but by time and the race-source rarely in source-code.
This means we have data races in http, database inserts etc. The source is usually not a concurrent task in source code-land.
Now you are pushing pixels. A data-race IS a kind of race condition.
My point is "races" happen all over. In concurrent code, databases, http and pretty much anywhere where you have some kind of timing, not scoped to a unit.
A race condition is an application invariant violation under concurrency, so it has no application-independent definition. A data race is unsynchronized access by two concurrent threads to the same memory location where at least one access is a write. Ergo, the definition of a data race has nothing to do with application logic.
I think this should make the distinction between data races and race conditions pretty clear.
A data race is by definition a class of an race condition. This is basic compsci literature, and there is no other way to put it, as even a non programmer can see the similarity.
Not sure why you would be that nitpicky for something so trivial?
I find this distinction extremely useful in practice because it explains why a static analyzer like Rust's type checker can prevent all data races but can do nothing about race conditions. (Similarly, a dynamic analyzer like ThreadSanitizer can detect data races but not race conditions, because it knows nothing about application logic.)
Meh.. sure a DR is not the same as an RC, but i would class it as a subset of the same thing. You you cant have an RC, you cant have DR, but the other way around.
In the end its the same problem, dressed up differently.
This is not generally considered part of the "memory safety" contract. You can not lift a nil pointer exception into a replacement for Go's "unsafe" library.
When we finally rid ourselves of C and C++ is so larded over with extensions and additions and features that we can finally plausibly say the C subset is just not in use anymore, we can perhaps consider as a community expanding what "memory safe" means, but in the meantime it has some very important meanings and we should not try to augment the term. Memory safety doesn't mean anything like "forcing exhaustiveness into sum type deconstructions" or "never has a race condition" (though it does mean said race condition shouldn't be something that allows you to escape out of an array or forcibly change the type on something in a way the language doesn't normally permit) or any of several other things that may be very nice to have indeed, but are not part of the definition of "memory safe".
Memory safe is a very old concept, and almost everything is memory safe now. But not quite, and as such the term still has use. And also zig for some reason gave it up so it won't be disappearing as soon as I'd like.'
> The download button doesn't even work properly. Clicking download in the top right gives me a .dmg, the other download button in the hero gives me the .exe, the one in the footer gives me a .dmg
I mean, it works for me?
The site is clearly not ready and maybe they didn't expect people to find it, but that doesn't mean the site is bad.
It is just a work in progress.
I'm not even interested in the site anyway the software and the source interests me more.
In actuality, successful open source projects recruit developers by providing value to them. If there's a failure before you even install the product, there's 0 reason for someone to start contributing right away, why not start their own project at that point? Contributing 1 to something that has 0 value is a donation in exchange for nothing, not how Open Source usually works.
Yeah... people aren't paying Bloomberg $31,980 per year for a TUI. They're paying for the data source... and I don't think you have Bloomberg's connections.
Asked a dear friend in the finance industry what he thought about Bloomberg. He's the type of guy who uses these systems daily. Mostly paraphrasing:
1) Bloomberg was lightyears ahead of anything else in the pre-internet days, so there's a lot of UI familiarity.
2) Bloomberg's chat is important because, as a hedge fund or investment bank, the chat is how you buy and sell bonds. You agree to the trade in the chat, then tell the back office folks to execute the trade. Direct quote: "I'd wager 90% of the ~400 trillion in annual bond trading value happens over Bloomberg DM"
3) Bloomberg is the biggest and best aggregator
This is fascinating to be because I always assumed latency was the key. After all, the only Bloomberg terminal I've ever seen in person was hooked up to its own dedicated fiber drop. It seems like the chat and sheer breadth of data are the differentiators.
I've heard the same thing about Bloomberg's chat many years ago. Since everyone you're chatting to also has to fork over ~$30k/yr to use it, there's the implicit assumption that you're talking to a serious person.
Slack (acquired by Salesforce in 2021 for $27 billion) started out as a chat app built for the devs of a failing online multiplayer video game called Glitch.
Used Trello a lot before it got sold to, and damaged by contact with, Atlassian. FogBugz looked cool…but I had to use an old version of Bugzilla.
I didn't know Glitch existed until this site had a notice that it Glitch would be shutting down. Surprised me FCS had anything to do with a game, and seems it wasn't a good fit. I like the style though, and downloaded some of the art and variations on the Groddle theme before it died.
I find it a bit less funny. There is this perception that what finance people do is super important and grown up but following a brief stint in the industry I realised it literally is just a game. We used to trade bits of stationery and trading cards for fun at school. They never stopped. The only difference is people who never consented to any of this are paying for it all, especially when it all goes wrong.
I assumed they were referring to market crashes caused by irresponsible levels of risks and deceptive practices like we saw in 2008, and/or government-funded bailouts
> the bottom rungs are almost completely populated by silver-spooned nepo-babies
You’re thinking of investment banking, corporate finance. Trading has always been the place folks from less privileged backgrounds got into finance. In the old days, Jews. (Like, into the 50s.) In the 80s, poor schmucks.
I know a lot of traders from both university and growing up around rich kids. Their parents are invariably very wealthy. They were the ones who had the time and safety net to sit around on computers all the time (like me becoming a programmer)
I’m not in the trading world though so I haven’t met the ones that don’t fit this description.
But exactly zero of the people I know who were raised in either poverty or mediocrity are traders or involved in finance, aside from maybe accounting.
Of course, this is all anecdotal - but I’ve only ever seen Bloomberg terminals outside of office settings in the apartments of wealthy children.
Perhaps things were a bit different decades ago, in the scrappy past, but it feels like most higher earning spheres are closing in around pre-existing wealth.
I was. Algorithmic derivatives. The rich kids went into banking. Their connections bought deal flow. Those of us from public universities mostly went into trading. It’s why it’s been looked down on within Wall Street since basically ever.
> I’ve only ever seen Bloomberg terminals outside of office settings in the apartments of wealthy children
Parents buying their kids Bloomberg terminals aren’t looking for them to get into trading, they’re training them to start a hedge fund.
(I’d also guess a minority of folks with a BB are traders. It’s really more of a vetted calling card.)
You know _traders_ who came from wealthy backgrounds? That's a completely incongruous outcome in my experience. At least in the markets I'm aware of from my career (commodities and fx) the trading component has effectively always been a middle class activity. Something that the kids of cops and plumbers did if they didn't want to go into the family business.
That has changed in the last 20 years or so but only because those jobs have effectively gone away. They are the factory jobs of the finance world. They succumbed to the automation impulse that started in the 80s and reached its zenith in the early 2010s. Traders basically don't exist anymore, a computer can do the job much more effectively. So much so that I was shocked when I _encountered_ a real live trading desk as part of a recent job move.
Bloomberg Terminal is that equivalent. Like, imagine if RHEL had an integrated live service TUI and integrated chat messenger system for customers, and you’d get about the same result except for a Linux distribution discussing packages and kernel patches and such, right? And since everyone using it is a paying customer, they can be taken for granted as likely being a serious participant rather than a bot/troll.
Nuclear Phynance at one point was incredible. Really one of the best forums for any subject I have ever been on.
I think it is completely gone now.
I have never used bloomberg but my understanding is it has history, network effects and great data.
The data is ultimately the problem with any project like this. Data is not cheap for personal use. For redistribution in a commercial product, it is really a huge bottleneck to get anything off the ground.
This just looks like the standard , useless, retail trading software IMO.
There is a marketplace on Bloomberg where you can buy and sell interesting stuff you don’t really find anywhere else. Some of it stored in freeports and delivered to your freeport, etc. top tier escorts, etc.
The terminal is also sort of an app platform for brokers and other firms to sell services to the buy side.
A few examples:
1. As a researcher, you can develop indexes and portfolios, then make those available to customers via bbg
2. Goldman has a service that let's you buy equities via SWAPs, if a fund can't hold said equities for regulatory or operational reasons. The whole service is a series of menus within the terminal.
3. Many brokers offer automatic trading services like "sell this notional but do it very slowly" etc etc... they do that via bbg
It's really only a specific subset of traders that need close to zero latency. Many other finance professionals deal on larger timescales so it's not that big a deal. I am more "finance-adjacent" so I don't use Bloomberg personally but have worked on plenty of deals where "time sensitive" means "it has to get done this week. Oh wait, the bank hasn't finished its KYC checks yet. Okay, it definitely has to get done next week. Unless the KYC checks are still ongoing, in which case, for sure gotta get it done by the end of the month".
Y latency doesn't matter if a human is looking at something. By the time your caveman-speed brain reacts, an FPGA sitting in an Equinix data center has made a hundred trades.
Bloomberg Terminal is for humans. It takes about 10 clicks to do a stock BUY. your average retail stock trading platform is much quicker, many have 1 click trading.
The dedicated fiber drop was most likely for reliability, not for latency.
If you want fixed-income data, Bloomberg is the only shop on the street data-wise.
If you want other financial data, Bloomberg's fixed entry-point pricing tends to make more sense in terms of bang for buck than its competitors modular price sheets.
People saying Bloomberg is just about the chat are simply embarrassing themselves.
Look at the price sheets of Eikon, Factset, CapIQ etc. There is no such thing as a cheap "Bloomberg killer".
Quality data is expensive. So are the leased-lines it arrives at Bloomberg on. So is the data wrangling architecture.
Bloomberg is also a channel for other data providers. You can access your gas pipeline flow data and index prices, which you buy from SP Global, via Bloomberg, for example. It brings data sources into one place.
It's a bit ironic that in a country with free markets, so much of the data that is relevant to modern finance is proprietary and quite expensive.
The exchange/marketplace is the oldest business in the world. How absurd that in 2026 seats on exchanges cost millions and the entities that control exchanges are mechanisms of gatekeeping rather than quality control -- the cronyism shown to SpaceX reveals just how corrupt it's become.
A stock exchange is nothing more than a marketplace. Anyone can start their own (the challenge being, getting a bunch of companies to want to list their stock with you).
That freedom is actually why it's hard to create a Bloomberg competitor - in order to provide their data stream, Bloomberg has to have partnerships with hundreds of companies worldwide who run exchanges for stocks, bonds and other instruments. If exchanges were government-controlled rather than free-market, there would be more centralization and getting the data together would be easier.
> A stock exchange is nothing more than a marketplace. Anyone can start their own (the challenge being, getting a bunch of companies to want to list their stock with you).
Not really true. I can't just start a stock exchange. I need to comply with a bazillion regulations. Then I need a license, which I won't get.
As much as the crypto space is disliked, it also showed what happens when regulation isn't stopping you. Exchanges would pop up and anyone could create one. You didn't have to be already wealthy, a spin off from a hedge fund, a connected family, a connected person. You could just do it, and if it was good enough, people would trade on your venue.
Then, probably correctly, regulation came, and now that is all gone. The little person can't do that any longer, it is now reserved for the elites again.
There was also a lot of fraud and mismanagement. People's crypto vanished and no one at the exchange was able to reconstruct how because there was no sufficient security and no real bookkeeping.
There is a lot of regulatory capture in the financia sector, but that does not in imply that no regulation is necessary at all
> They're paying for the data source... and I don't think you have Bloomberg's connections.
We keep seeing hundreds of Bloomberg competitors mimicking the interface and they always forget that the chat (with the connections), data and the newsroom are the reasons why Bloomberg's network effect is close to impossible to break.
Using the Bloomberg Terminal is taught very early at colleges for any finance professional, which is how they get them as well.
Are they trading bonds, equities, credit default swaps, options,
, etc in large dollar amounts? “Finance” is pretty broad, Bloomberg is for traders and I-bankers afaict.
Seriously. I see a cool product that someone built and is sharing with the community, and the top comment is basically a criticism that it's not a $31k terminal.
Well yes, but a lot of people immediately jump to conclusions based on name alone, it's human nature. Definitely something to consider when you're picking a name for a project.
An example that comes to mind is JSON5. People have a visceral reaction to the name, it sounds like it's trying to be HTML4.01 -> 5 but for JSON. In reality, it has its uses but doesn't supersede JSON whatsoever. The name itself has given it a bad rap though.
If you pick a name like "Gloomberb" the most obvious interpretation is that it's a Bloomberg alternative.
Financial companies are cutting down on the amount associates can bill the firm for a $30 dinner, and the time before they can have the firm pay for a $30 car ride home. They definitely wouldn't pay for Bloomberg if it could be easily replaced.
Bloomberg terminal is only $133/day (assuming 240 work days per year). So, while $32k/yr seems expensive at first glance, given the total annual cost of an analyst or trader, it's not huge. Of course, they'd rather not spend the $32k/yr if they could avoid it, if bloomberg can give you an edge on just one or two trades a year, you come out ahead. So...
I can say companies with less than 20 mil arr pay around $150k a year for saas and others (sometimes the same) also pay 50k a year for a niche agent harness.
Making a bad trade or missing a good one due to delaying data or bad data can pay for several years worth of bloombergs for everyone in your firm in one moment.
It's really useful to have a chat app that is gatekept behind a 20k/year+ subscription. It's a particularly useful signal if someone is offering you a million+ dollar asset for sale.
I get that, was more curious if you knew how much that is used for signaling and the traffic there. I sort of expected these communities to exist in other sources (like regular SMS / Slack / private back channels etc).
I'm going to copy-paste one of the comments from ryukoposting higher up in the thread because I think it's relevant here:
> 2) Bloomberg's chat is important because, as a hedge fund or investment bank, the chat is how you buy and sell bonds. You agree to the trade in the chat, then tell the back office folks to execute the trade. Direct quote: "I'd wager 90% of the ~400 trillion in annual bond trading value happens over Bloomberg DM"
You may discuss trades via SMS or Slack; maybe you're important enough that you have a broker, and you send them your idea. But the broker at the investment bank is probably handling those trades via Blomberg terminal. That's the network effect: all the bankers are in Bloomberg chat, and it is therefore the easiest place to find who owns an asset and negotiate a trade.
Also, and in addition, the value of the Bloomberg Terminal is not the UI, it is the consistency. You don't pay for an accelerator and a break pedal, you pay for the 100% guarantee to find them in the place >100k people have been trained to find them.
Can't you just use a bunch of agents to extract financial statements from company websites the moment they are published? OK, no insider info but you can still do quick agentic fundamental analysis and decide which companies are interesting.
If fundamentals matter for stock performance, sure yeah. I would be interested to see the results of trying that against the kinda alpha wall street uses usually
Some folks do fundamental analysis, some do technical analysis, most do a mix of those. You don't need Bloomberg terminal to extract fundamentals nor alpha. Maybe a better example would be S&P Capital IQ - you can essentially replace it with agents doing the web searches and extractions for you. Another 20-50k saved.
The US publishes financial statements for free on EDGAR. But then you have to parse the unstructured data, normalize it so you can compare a bank to an airline to a manufacturer and then you have to accommodate mergers and acquisitions throughout history and every revision a company makes for prior periods, and then you're starting to talk about real money and the price of Cap IQ or Compustat or Factset starts to look pretty attractive, especially if your alpha doesn't come from your proprietary methods of databasing financial statements.
You're paying for direct lines to these firms. It's a big chat/social media platform. Combined with the data and news and you got yourself a hell of a platform
actually a lot of data is not included in the standard bloomberg license and you have to pay extra (mostly passing through to the data vendors) to get access to it.
There is not a single reason for Bloomberg’s dominance but the one feature that keeps people on it is the chat.
AI Creators and NFT Bros are cut from the same cloth. Just polluters who think because they can type on a keyboard it makes them special despite having spent most of their lives as talent-less hacks.
Isn't this basic economics? Supply and demand. If slop floods the zone then human work becomes even more scarce and valuable.
What is my incentive to pay you? A person who spent no time working on something and who probably won't spend any time working with me if I need support. You're literally a meat puppet and a useless middleman when I could pay $20 and do it myself.
Unfortunately we've experienced the basic economics of spam. It costs virtually nothing to spam emails and so the spammers exploited that. Now it costs virtually nothing to spam markets with AI slop. Platforms need anti-slop filters and the easiest one is to charge x dollars per model to publish there.
yep basic longtail effect. back in the day at a PRO (performing rights organization -- music copyright stuff) we would analyse the longtail to death because the ~10% artists would get ~90% of play time (=> apportioned funds).
i guess in this case and probably some other cases that AI slop is just bulking up the longtail even more than before. 90% of people don't listen to AI generated music, it's only weirdos on HN that i've seen claiming to want access to it for personal listening.
I don't think its asking too much of a $1T company to not make a shitty desktop app. Especially when that companies whole moat with developers is that their tools can do our jobs better and faster.
The real reason they're using Electron is that some PM is comfortable with it and since nobody is reading the code, they use that comfort as a crutch to release most-likely working desktop app.
When the creator of a project has infinite money, infinite labor, and infinite incentive to lock more devs into their platform via skill atrophy and the product is still shit, that's the human in the loop.
> I strongly agree that written text should be from humans to humans. Yet I still write all of my texts with LLMs. And I don’t find that contradictory. What distinguishes “AI slop” from “good writing” is whether a human has put thoughts behind it. And you cannot outsource thinking.
Writing is thinking. If you're outsourcing your writing to an LLM, you are shortchanging yourself by skipping over much of the refinement of ideas that the process of writing provides.
I wish the author had clarified how he uses LLMs for writing. It's perfectly fine to have an LLM proofread and fix your grammatical errors--that's a mechanical task. But I think it's gross when it starts putting words and content on the page.
We were so spoiled. We got fat salaries to sit in air conditioned Herman Millers all day learning about computers. Now we discover a way to synthesis intelligence and the only thing we can think to do with it is ruin the most fun career most of us could have ever hoped for.
Sure, we're all more productive now, but how much of that is because we leverage AI on top of the intelligence we gained from all of that manual work? Who is to say that in 36 months you're not a worse developer over all because that systems knowledge starts to atrophy too?
This isn't me saying you shouldn't use AI. I use it all of the time to do useful side tasks like to setup GitHub Workflows while I write a feature, or with my agent on a VPS to do internet tasks for me. It's nice to have a little synthesized intelligence.
What isn't nice is to supplement your own intelligence. I think the gains are in the work there--similar to how you can be absolutely ripped from taking steroids while destroying your body. Often it's the shortcuts that are the most treacherous path.
I’ve been trying to ask people a different question: sure, we’re more productive now but to me, the AI era is only serving to plunge us deeper than ever into producing more, more, more, faster, faster, faster. And for what? What’s it all for? I became a software engineer because I have a lot of fun writing code, thinking through and solving complicated problems, and experiencing the reward of seeing what I’ve built by hand working for the first time.
Do people really have fun managing a fleet of agents that generate the code instead? Or is it just the rush of producing something extremely quickly, much more quickly than you might be able to alone, regardless of how well (or poorly) it might work? For me, being able to move quickly was never the fun part.
It’s one thing to utilize AI to lessen the drudgework, the boilerplate, but I look at people who have gone all in on agentic development and it just really makes me wonder.
> I’ve been trying to ask people a different question: sure, we’re more productive now but to me, the AI era is only serving to plunge us deeper than ever into producing more, more, more, faster, faster, faster. And for what? What’s it all for?
Many devs here have stated that the fun part for them is seeing the end product, not the act of creating it. Using AI is an act of need satisfaction.
Unfortunately, cloning a GitHub repository or downloading a Squarespace template doesn't hit the spot, because you can see exactly where the code came from, so your brain knows you were not the one responsible. AI's greatest feature is that it obfuscates provenance. You can now happily clone that repository or download that template without the feeling that you're cloning someone else's repository or downloading someone else's template.
It is why I feel dirty after AI generates a piece of clever code: I know I am stealing somebody's IP without attribution. And the AI companies benefit from this, not the real people behind the training data.
People who use coding as a means to an end, producing a product
People who enjoy process over product and coding is the enjoyable part, not the end product
Company executives fall into bucket 1. Even if you love your cushy air-conditioned job, doesn’t mean the people above you don’t see you as a means to an end, a better product.
Solo founders and small startups are in bucket 1 as well but that doesn’t mean that don’t enjoy coding, just the product being made is much more satisfying.
I think that’s a false dichotomy. I enjoyed coding but was more interested in the problems code could solve. Both were really important facets of the job. When I was a chef, I loved being creative with flavors and techniques, and giving people a new favorite aesthetic memory to file away. Losing one of those things would make the job not worth it to me even though I enjoyed both.
Great point. I learned to code to solve a problem and fell into love with programming as much as the product building. Now the first part is gone and I’m forced to decide which was more enjoyable.
I do think food is a bit different. With software and businesses, the end product keeps on giving and can be forever changed. For food, the process is many times longer than the actual eating the food part.
Brother, there was slop before AI and slop after AI.
Pre-AI slop got a pass because the creator probably worked tirelessly to make it and that process gave it value.
Post-AI slop get criticized because AI can create it so fast and easily.
But the builder has not changed. Because the builder knows that the product depends on iteration and polish. And knowing what to iterate and what to polish requires intuition and taste. And thats the thing about taste, its forever fleeting. What we think is AI slop, was actually novel and coveted at a point before AI existed.
Many developers became developers because of the paycheck, but they never particularly enjoyed the job, so if instead of working they can twiddle their thumbs waiting for the agent to make attempts at fixing their ticket, they prefer it that way.
I can clearly identify this kind of developers at work by their mindless enthusiasm for AI. Development is just another job before they can move into "management" and make all-knowing statements all day long.
> producing more, more, more, faster, faster, faster. And for what? What’s it all for?
If you wanted a literal answer, it is to accelerate revenue as much as possible to make the very rich people who own most of the company even unfathomably richer. No benefit to you for making more faster. Other than the burnout, that's all for you to enjoy.
Please stop saying we - because many of us didn't ever desire or contribute (outside of having our code / data / IP stolen) to these models or the companies developing them. Many of us weren't willingly singing up to use AI - we were essentially forced to by our employers. Not everyone is more productive now because of AI - many people spend the extra time they save writing code, reviewing code produced by AI.
Yep. My job was code review heavy before AI. Now it's even worse because I can't even trust that the developer understood what they were "developing", so I have to be even more vigilant. I may have to institute a "prompt review" process for some.
> We were so spoiled. We got fat salaries to sit in air conditioned Herman Millers all day learning about computers. Now we discover a way to synthesis intelligence and the only thing we can think to do with it is ruin the most fun career most of us could have ever hoped for.
True.
> Who is to say that in 36 months you're not a worse developer over all because that systems knowledge starts to atrophy too?
I think that would be the best case scenario for a lot of developers. It’s not going to make anybody’s life easier. The labor market and job expectations are morphing to absorb any increase in productivity already, and we will all be forced to produce more and more and more to keep our jobs. Demand can’t instantly dramatically increase to meet the productivity, so it’s not like companies can just sell more— people will get laid off. More and more people will be fighting over fewer and fewer jobs, so the people who are still employed will get paid shit. It’s a basic supply and demand equation.
I wonder how many fewer people that told me “well my job isn’t going to be affected because it’s too complex/specialized/etc” in 2024 would say that today?
Companies must either double down on increasingly exorbitant per-token pricing and reduce payroll to compensate, or decide the tradeoffs aren’t worth it, and double down on human intelligence. I think the economics of the industry are going to decide for us in the coming months.
if computers themselves are bicycles for the mind, LLMs are cars. or even motorcycles, if we talk smaller models.
- they require specific roads being paved for them. for example, if your tooling is proprietary and not accessible from the CLI, your agent is pretty much fucked. if your tool is not represented in training data (think, `jj` VCS or your proprietary/tailor-made tooling), you require duct tapes such as "skills" and "memories". a bicycle (that is, your own mind + computer) handles such off-roads much better.
- they get you from A to B faster, sure, but along the way you may encounter something curious - a different road to take, an interesting vista. not to mention, bicycles are actually good for your health, and professional drivers suffer from all the sedentary job diseases we programmers do, unless they actively counter it. with LLMs, we get a "sedentary job disease" of skill atrophy, on top of all the other atrophies us coders should counter with a proper exercise set at least three times a week.
- finally, when you crash in a car (Opus/Sonnet, GPT-5.5) or, worse, on a motorcycle (smaller Qwens, DeepSeek, Haiku/GPT-5.4-nano), you crash very loudly and with a high chance of irrecoverable casualties.
The bike/motorbike/car analogy is good. In each you can find enjoyment that suits your character.
I have been drawn to coding from the first day I took a course at college learning Pascal and assembly on an IBM PC. Hell I even wrote an IEEE/488 driver for an Osborne 1.
As an experimental physicist, coding was always central to my work. I always felt guilty because I had more pleasure coding than tackling the physics itself.
This is a new age we are entering. AI changes how we do things, but I believe that the human passion to be creative and do intellectual work will always be part of it. It's in our nature.
So I'm not worried that we'll all dry up and turn into zombies.
There's one more: The "bicycle for the mind" analogy was one Jobs chose specifically in reference to the fact that a human on a bicycle moves more efficiently than a human on foot—or any other land animal for that matter. But it's still the human's own effort that propels the bike. Motor vehicles require an external energy source, the human only directs it. Similarly, with LLMs, it's no longer the user's own effort that's doing the thinking.
> There's one more: The "bicycle for the mind" analogy was one Jobs chose specifically in reference to the fact that a human on a bicycle moves more efficiently than a human on foot—or any other land animal for that matter.
One of the canonical references of Jobs’ use of “bicycle for the mind” also compared the efficiency of locomotion to the California Condor which was (I’m working from memory, here) 17X more efficient than a human walking.
A human on a bicycle, according to Jobs then, is more efficient than the most efficient animal locomotion known to humankind. The comparison included animals moving through non-terrestrial environments.
And, like cars, our federal/state governments are lighting astronomical amounts of cash to subsidize the infrastructure that makes them operate at the scale they currently operate at.
Just one more ~~lane~~ datacenter, bro. That'll fix it; trust. Please. One more ~~lane~~ datacenter. It'll be so good.
You're either using it wrong, or work somewhere that sucks. I'm having a ton of fun coding with AI.
I feel like I am learning a whole new branch of the programming skill tree. LLMs and their harnesses are like a mew set of constraints to work around when designing systems, but if you get them right you can build bigger, better things than ever before.
I say all of this as someone who spent the last two days rebuilding RBAC for my application after Claude royally messed it up.
I attempted to build a K8s based image catalog and management system a few years ago, and progress was very slow. Took 2 months to get the first vaporware demo put together.
This year I'm building and IoT data management platform and I've already built two demos of the product and am adding a bunch of features for a third. Nothing is vaporware about it. All in about 4 months.
The big wins have been system config, debugging, and exploration. I was able to build an Arrow Flight SQL backend to use as an interface and try it out with some use cases, decide it wasn't going to work, and replace it with something else, all in about two weeks. Would have taken far longer before, if I would have been able to do it at all. I knew nothing about Flight SQL before trying it out.
I shit you not I have been told to "stop trying to understand it, just make sure it works" when mandated to use LLMs at work, like the absurdity of that statement isn't self-evident.
Needless to say I have been looking for a way out of this job (and likely career) ever since.
What's going to happen is people who give a shit are going to get filtered and self-select out of the job, and then the entire field is going to be dominated by dunning kruger AI maximalists. The "AI will replace engineers" is true, but for an entirely different reason and entirely different way than most people making that argument think.
