Claude Code seems a lot more stable than Cursor Agent. I've had it run for 15-20 minutes on a single prompt, debugging, testing and fixing bugs. Also haven't seen network timeout or file edit failures.
Works for me a lot of the times with Telegram Saved messages(similar features to Signal). But some devices won't be my personal so no access to Signal or Telegram
I would say we're much more focused on the infinite canvas and Figma-like experience. We also do not build on top of WebContainer [1], which is commercially restrictive and closed source [2].
I agree. There's really no magic to it any more. The table create DDL commands are a very precise description of the tables, so almost nothing more is ever needed. You can just describe in detail what query you need, and any decent LLM can do it just fine.
Because there was nothing else quite like it at the time most enterprise software was created or recreated.
And it's still stable, fast and reliable with a massive ecosystem of stable, fast and reliable libraries and software. With good developer tooling, profilers and debuggers to go with it. And big enterprise support teams from RedHat, Oracle, IBM, etc. throwing in their (paid) support services.
It might not be the best language in any of the categories (speed - runtime and compile time, tooling, ecosystem, portability, employee pool), but there's pretty much almost no languages that are as good in all categories at once.
And to top it off, JVM can host other languages so it can easily interoperate with more modern takes on language design like Kotlin while still running on pretty much all major operating systems used in the wild and most CPU architectures as well. It'll run on your car's SoC, your phone and on your server. In many cases, using the same libraries and same code underneath.
I believe there were alternatives at the time, but expensive. Java was free and also syntactically compatible with C++. I think that rather these properties (than being somewhat unique) are the main causes of its success.
That’s just obtuse. Compare Lisp, Forth, APL, Prolog, Ada, or Fortran. Java is just C++ with a few twists. You can literally write code that will compile in both.
That's exactly how I meant it. Another alternative to Java at the time was Smalltalk, with different syntax. Choosing C++ syntax for Java was clearly a marketing move (as it was for C++) - we shouldn't underestimate network effect of familiar syntax.
I think Java succeeded for the same reasons C++ succeeded - built on familiar syntax, reasonably free and "supported by" a large company. Java being a decent language is a consequence of its success more than of its original design.
That code will it just needs to be in the proper context. No the same file will not compile, even if only because javac needs files to end with .java .
I worked in IT from the 90s to today. My perspective is it grew and grew because Sun supported it, then IBM supported it, RedHat supported it. It had the glimmer that it was the "Enterprise Way" of doing "Real IT" programming for "Real Businesses". I am not saying any of that is the "Truth", just the perception that was held by the majority of people who could choose what to write enterprise code in.
Microsoft had C#, at one point IBM pushed SmallTalk. C++ for these environments is doable but going to slow you down at development a lot, as well as being much harder to secure.
At that time the dynamic alternative was Perl, and that remained true basically until Rails came along.
I am not sure. C# came long after Java already made inroads into the Enterprise space. It was a different time.
I would say that many things in IT are not chosen on technical merits alone. You have people that do not want to accrue any blame. Back then, by choosing what IBM endorses or what Microsoft endorses, you absolve yourself of fallout from if and when things go wrong.
Back in the 90s, it felt like IBM, Redhat, Sun kind of, sort of, got together and wanted to keep Microsoft from taking over the Enterprise space by offering Java solutions.
Right. Before Microsoft created .NET and C# they first tried to play their "embrace, extend, extinguish" trick with Java. They released a JVM and "Visual J++" language which was sort of Java, but had incompatible proprietary extensions to lock customers in to Windows. Eventually they were forced to stop that for legal reasons so they completely dropped all Java support, and built their own replacement virtual machine and associated languages from scratch.
Yes, its early popularity was very much management-driven, based on magazine articles and the like. Its object-oriented design (often presented as if something new) was supposed to make programmers fungible, and its portability was supposed to let you build an app that would run on anything. And it had a Real Corporation behind it, which appealed to corporate management.
In the late 90s, I got stuck making a scheduling program in Java, but it had to run on the 16-bit Windows systems of the time. That was a huge pain, because the 16-bit version didn't have all the capabilities that management was expecting based on the hype. These days, I sometimes have to install enormous enterprise applications that tie up north of 32G of RAM even though they're just basic hardware management tools that would take a fraction of that if built in something like C++ with a standard GUI library. I manage to avoid Java most of the time, but it's been an occasional thorn in my side for 30 years.
It's safe. It's easy to hire anyone from anywhere to write Java. You generally can't create an ungodly mess apart from layers and thousands of classes. There's a library for almost everything. It'll still be around in 10/20 years. It's good enough
Decent tooling. Been around for long enough that a lot of the quirks of it are well known and documented. Basically it's a blue collar programming language without too many gotchas. Modern(ish) day Cobol.
(I'm predominantly a Java dev still, even after diversions over the years to Javascript, Python and C#).
Java beta & 1.0 were released my Freshman year of college and I've been writing Java ever since. With the exception of one job where we tried to write a Java-style Enterprise security cloud application in Python every commercial product I've worked on has been built in primarily Java, often times with other languages on the edges of the application.
The key thing I think with Java is the programming model & structure scale well with team size and with codebase size, perhaps even in a way that tolerates junior developers, outsourced sub-teams, and even lower quality developers. All of those things end up becoming part of your reality on big Enterprise products, so if the language is somehow adding some tolerance for it that is a good thing.
The other things around Syntax and such that people complain about? Those are often minor considerations once the team size and code base size get large enough. Across my career there has always been the lone guy complaining that if we did everything in a LISP derived language everything would be perfect. But that guy has almost always been the guy who worked on a small tool off by himself, not on the main product.
Java has changed a tremendous amount as well. A modern Java system has very little in common with something written before Generics and before all the Functional code has been added. Where I work now we have heavily exploited the Functional java add-ons for years, it has been fantastic.
on one level this is clearly “shipping the org chart”, but… honestly, even as no fan of Java this is clearly efficient on many levels, especially when you consider the humans and org to be part of the system (which everyone should. or it’s just my HCI brain talking.).
Another way to look at it based on coming across it in enterprise:
How did he build something adopted by so many enterprises?
It does some things at scale very well and has been afforded the performance improvements of very smart people for 30y.
It’s not to say the language isn’t verbose, one of my favourite features was the ability to write code in other languages right inside the a Java app pretty well in-line by using the JVM, thanks to JSR-223.
It was possible to write Ruby or Python code via Jruby or Jython and run it in the JVM.
Consider that in the mid 90's when it arose, most organisations were writing business code in C++ and paying license fees for things as simple as string handling libraries. There was almost no good solution to cross platform network code. RPC calls required things like manually dealing with byte order.
Then most organisations had deployed windows for staff but needed to run things on Sun servers. Java was a god send as a free and actually cross platform solution that let devs work on windows and run the same thing on the corporate server infra without changes. The culture at the time would not consider deploying scripting language sfor full scale applications acceptable, so Java with it's C++-like structure but built in cross platform capabilities and generous stack of batteries included libraries (for the time) was an absolute god send.
it hits a sweet spot of reliable, C-like, fast enough for most things, with a ton of library/framework support. plus Sun and later Oracle pushed it hard in the 90s/00s. it'll be the new COBOL.
