488 karma · joined September 18, 2019
My guess as to why this issue is left open? Google has global timeouts set on all the network edges so they don't want each service to use its own. Whats good for Google overrides whats good for the supposedly open source project.
This is pervasive in most of their projects. Google open source is like the Reapers from Mass Effect series. They leave some crumbs behind to ensure the software ecosystem develops along desired paths. Not out of charity, they do it to ensure a successful harvest.
It has all of the safety characteristics of a VM language but its low level with no runtime. Its a direct replacement for C with all the performance and modern design of languages like Java and Go. And it uses LLVM so FFI with other languages that compile to native is simple and zero overhead. You can even do whole program optimization (LTO) on the combined binary, that's huge. Trust me the hype about Rust is real.
Much more real than the hype around Go, which to me just feels like yet another GC language. The hyped AOT compilation is nothing profound. Since the GC forces Go to have a runtime anyways IMO they should have gone all the way and just used JIT. And Go doesn't use existing C compilers so FFI has overhead, can't be optimized together at a bytecode level
Try one of the many browser extensions that spoof Chrome useragent. For me it makes a big difference on Google search results and Youtube
Microstructure interference can create blue, but perhaps not the flower pigments themselves
Some examples from crufty Java world. You magically get connection pooling with any JPA provider. If you import a logging library, it magically works. Flyway and Liquibase db migration tools have built-in failsafes, and "just work" with defaults.
I think Ruby suffers immeasurably from most things being built for Rails. In Java and Python, there's so many options that everything is forced to be modular when running standalone and play nice with various frameworks.
Ruby is loved for Rails, but Rails is slowly killing the langauge by making it hard to do anything without it. For most purposes, Ruby is Rails. To me this is a good reason to use a different language where I have flexible options
Donating my meager highschool pocket money to help buy the source code ended up being the most impactful thing I've done in life so far.
Google maps might be a good example, MapQuest and Terraserver used to be better for navigation and satellite photos. Did they fail because of business reasons or self promotion? Hard to know, but Google pulled the same shit as MS got antitrust for. Bundling their own maps app pre-installed on their dominant mobile OS
Its also impossible if you have any health problems, or need to save for retirement or have student loan debt.
Its really only possible if you're young and healthy, so this would filter out probably 80% of adult population
I didn't know this was even possible/legal. Start as a non-profit for all the tax advantages and convert to for-profit once you've got a saleable product? Maybe startups should start doing this
In a couple benchmarks Java would probably be faster than C++ if the JVM was allowed to warm up
Long running VM's like Hotspot in "server" mode do a lot of expensive optimizations over time. Benchmarks game makes no attempt to warm up these VM's, so it doesn't actually measure how fast a VM is in practical hosting scenarios.
Anecdotally, I have heard that Java is still faster than C# in most benchmarks when both VM's have had time to do a full JIT. I've also heard that Golang is much slower than C# and Java when their JITs are allowed to fully warm.
I've been meaning to build a "warmed up" version of benchmarks game specifically for testing VM languages but never got around to it. If someone else wants to pick up the torch I would be eternally grateful!
Adopting HK citizens is a far easier sell than Syrians. They already speak English, are highly educated, wealthy, westernized, and have special status in UK law.
Letting a ton of refugees in is a large burden on the host country. They don't share British culture and values, tend to have no education or marketable skills, are in poor health, don't speak the language, need a lot of government support, and depress wages for already poor citizens of the host country. It should still be done for humanitarian reasons but there's a lot of pushback from citizens for reasonable concerns.
With how low the pause times are with Java's new collectors (categorically not longer than malloc()), the only faster alternative is not allocating at all. Which you can do in many languages.
I agree your point the memory allocation and GC is expensive, but that's something you see in any language when allocating. It's not unique to the GC. You either pay the price with GC or malloc()/free(). Its the same price but one is much easier to deal with than the other.
If pause times lower than 10ms are important you could write your app in Rust which makes it much easier to systematically avoid allocations using borrowing.
I guess my point is that the new collectors make Java memory management roughly comparable to C, and if you care so much about performance that allocation costs are important, you should just use a language like Rust where its easy to avoid allocation completely. The performance gap between allocating in C vs Java is, for practical purposes, gone.
Angular is the J2EE/Plan9 web framework. They just keep layering on complexity when they find use cases that don't work. Instead of ratcheting down to give you more control, you get even less. The cycle repeats. Its way more than a web framework now. The templates you write are barely related to HTML and JS, an order of magnitude more divorced from reality than JSX
3 weeks is the reason that innovative projects usually die on the vine at established companies. PM's and bean counters never want to spend more than a few weeks on a "sprint task" that might not work out. The exact opposite of the mindset you want in a startup
New versions of VisualVM can also open flight recorder files
You could malloc() and free() so much that the code doesn't have time to do anything too. And these operations aren't bounded in time either. Just using C doesn't save you from memory allocation, its just done manually instead of automatic. In every system I've worked on you won't have this kind of GC pressure unless you do something profoundly bad
> The vast majority of shops" is an interesting metric given the vast majority had to pick a language before Rust existed.
true
Go collects VERY frequently to keep average pause times low, which hurts throughput. It also has pathological worst-case pause times, which is what the author ran into.
My suggestion of Java is just because its been used for high performance REST for decades. Rust has Actix and a few other frameworks, in Java you have 20+ options. Its a lot easier to get something off the ground when you're 99% sure you won't have to build anything except some glue code. Yes, Rust is faster, but is 30% better performance worth treading the wilds while you're trying to keep a startup afloat, I don't think so personally.
Using Java with Shenandoah or ZGC collector would directly handle their GC issue with rather boring technology
I've only seen this done in Go :)