kinjba11

Either they don't know better (the majority) or they use an alternative keyboard like GBoard

This reminds me of the concept I learned of recently: that metrics and simplified quantitative information has been digesting the world for a long time. Simplified metrics like 'pounds of strawberries sold' take over our value systems instead of more squishy values like 'humans enjoying varied and great tasting strawberries'.

The drive for 'number goes up' eliminates nuance and we lose something real but poorly quantified and thus not valued. And this dopamine fracking has been happening for a while, is the latest version of that. Whatever gets eyeballs and we can measure getting eyeballs, wins, despite the dystopian consequences.

The book 'The Score' by C Thi Nguyen goes into this, has given me a new way to see if something I value is actually just a metric I learned and unconsciously am following. He outlines 'four horsemen of bureaucracy' that have replaced more nuanced values: the need to scale (losing nuance and geographical variability), make something mechanical and repeatable (lose nuance and adaptability), replaceable parts (losing nuance, make everything fungible, humans as replaceable), and centralized control (lose individualized voices). These were great in the first wave as they've increased our standard of living and made e.g. mass production of medicine and such possible, but now as more ways are found to extract attention these forces are eating away at our lives

Zig plans to make LLVM optional. Rust has Cranelift. Go afaik has no dependencies on the C++ ecosystem including LLVM. Python and some other languages are built with C, not C++. So, progress is being made slowly to replace LLVM as the defacto optimizing code backend. Alternatives are out there, may they compete and win! C++ makes me pessimistic about the future of humanity..

This reminds me of the "three tribes of programming: mathematical poetry, machine hackery, and business value". I think each SWE gets similar but different feelings of satisfaction. I knew a coworker who cared about the result, and little about the code he wrote. This was foreign to me when I saw it, as I was and still am definitely in the love for "math poetry" camp when it's possible.

https://josephg.com/blog/3-tribes/

Yes, and being incompatible with GPLv3-or-later may be done on purpose to push folks into a commercial license.

What about restricting yourself is not healthy?

When I was a kid, I'd eat Trix cereal. I enjoyed it. Now - I find it sort of gross. It's too sweet. You can reach that same point with cake or pizza or a candy bar, etc. - in that, those foods become sort of gross. Foods like spinach become more satisfying. Not only that, but that satisfaction may yield a higher reward than you ever could with Trix cereal. But you'd never reach that higher level of satisfaction as long as you're eating Trix cereal every day.

My company recently switched to UHC for 2025. My regular monthly out of network claim was fine with Aetna. With UHC? After I filled out a long form with information in a PDF, they mailed me a letter saying they needed more information. The exact information I had already given them, except for one thing trivially looked up, the provider's phone number. They asked that I mail them more information. I don't have a printer. So I had to get PDFs, go to the library, print them, buy envelopes (yes they did not provide one) and stamps, and mail it. I have yet to hear back anything. I am going to have to follow up myself. Is it worth it to me to spend this much time? The frustration is real. Even if the doctor here is technically in the wrong, UHC deserves every negative press possible. What they pull should be illegal, companies like these are a big part of why our healthcare system is a joke.

Yep, for expert driven projects, such as Go and C#, it is nearly always a case of "everything is a tradeoff".

Another good article for comparing GC between Go and C# https://medium.com/servicetitan-engineering/go-vs-c-part-2-g...

This seems to be endemic to civilization period. Nobody pays attention until the last one breaks, and by then nobody knows how it's done anymore. I'm reminded of the fleet of ships that repairs undersea data cables, which are looking at aging staffing issues.

https://news.ycombinator.com/item?id=40075402 https://www.theverge.com/c/24070570/internet-cables-undersea...

I pay $173 per year for JetBrain's 'All Products Pack'. Considering the salary I make as a software engineer, and the quality of the tools JetBrains provides, this is a great investment. Rider works flawlessly for me, far better than VS.

As a side, it always strikes me as ironic that software developers are paid extremely well and yet hesitate to pay even a modest fee for the tools that enable them to do their job. Most "free" tools are not free - someone was paid to create them. IMO whether engineers are on a stable payroll is a differentiating aspect to why some tools succeed and become widely used and some don't. In the case of dev tools, our tech corporatocracy MAMA (Microsoft, Apple, Meta, Alphabet) pay engineers to make products like VS Code, then release for free. This is for eyeballs of course, because charging for the tools would get them nothing in comparison to their main platform revenue streams, which benefit hugely from the network effect.

It's in their FAQ.

> Why not develop Mojo in the open from the beginning?

> Mojo is a big project and has several architectural differences from previous languages. We believe a tight-knit group of engineers with a common vision can move faster than a community effort. This development approach is also well-established from other projects that are now open source (such as LLVM, Clang, Swift, MLIR, etc.).

https://docs.modular.com/mojo/faq.html#why-not-develop-mojo-...

Isn't that what this and other papers say - that AMOC is doomed to collapse, it's just a matter of time? I'm not sure I'd equate AMOC collapse to industrial civilization collapsing.

My understanding with climate change is that we have signed up for a lot already, but much more is on the way if we don't make big changes faster. Humanity is a crisis-motivated species. The trouble with climate change is the effects so far have nearly no impact on power. If AMOC were to shut down in 2030 devastating Europe's economy, that could be the wake-up call to everyone to actually stop fossil-burning ourselves to doom for short-term conveniences.

Not Just Bikes, a YouTuber made a video about increasing vehicle sizes in the US and why you may be interested in

https://www.youtube.com/watch?v=jN7mSXMruEo

I concur very much. HN is the only social media I use these days, after cutting reddit and others nearly a decade ago. I have had to set up blockers for the comments section, to limit my time, as I end up spending far too much time here. Even so, did I really need to spend the last few hours learning about corner-locked land, southwest's canceled flights, new rust features, wifi DFS, anecdotes about electric vehicles in winter, etc?

On the flip side, without HN, my life would be totally different. I likely would not have pursued the much higher paying job I have now. My enthusiasm for technology and software would not be as high, seeing the many ways tech is used here. I would not be aware of meditation, notion, chatgpt, ml, postgres, cloud, rust go, wait but why, the inner platform effect, and so much else. For better or worse, HN shapes my outlook on the world. Is knowing all this worth the time spent, or is seeking knowledge simply addictive? I don't know.

> or patch the runtime code

A huge spike in CPU usage would be treated as a regression in other language runtimes and would likely be addressed. The fact that this is solvable with advanced JVM knobs is both good and bad. Good in the way you say. Bad because the complexity of maintaining all those knobs makes it difficult if not impossible to improve the runtime defaults, and every runtime problem becomes a tuning problem.

Go does not have compile-time null safety or sum types :)

    foo := Foo{"hello"}
    fooPointer := &foo
    fooPointer = nil
    fmt.Println(fooPointer.Bar)
    > panic: runtime error: invalid memory address or nil pointer dereference

In a language like Kotlin a compile time error would prevent `fooPointer.Bar`, and in Rust `nil` does not exist. Go also does not have sum types, see for instance https://making.pusher.com/alternatives-to-sum-types-in-go/

> 5 days, 6 hours

Many remote salary workers regularly work 6 hour days. Getting more recognition for this seems like a good first step in getting acceptance for 4 days, 8 hours.

Looks similar to Sonic https://github.com/valeriansaliou/sonic (wr/in Rust)

Doesn't crypto have the same problem, with money laundering and other crimes? If you lose money with crypto, there is no one to sue nor government insurance.

Isn't this circular reasoning? Rails are terrible, so nobody uses them, hence nobody invests, hence poor ROI. Roads are heavily invested, so are usable to the point it is uneconomical to use any alternative, so roads get more investment, etc.

Rust doesn't have a garbage collector, meaning you have a steep learning curve around the borrow checker. Zig aims to be a C replacement, with manual memory management as well.

Nim is very close to Crystal. Some parts that might lead you to prefer Crystal however:

- Nim compiles to C code, meaning Nim is coupled to what C can do. I find compiling to C to be distasteful, C is not meant to be a compilation target. We should be getting away from C, IMO. Nim is limited to what C can achieve, and the design of the language trends towards "here's how this translates to C" as a result. Compiling to C is also an extra layer of abstraction, as now for instance with debugging you have to go through the C layer. Crystal like Rust uses LLVM

- Crystal also uses Ruby syntax, which many prefer. I have grown to dislike semantic whitespace such as how Python works, so this is a plus for me.

- Crystal has a garbage collector, period, and leans into that. Whereas Rust, Zig, and Nim want to give you complete control over memory, Crystal is more focused on being a better high-level programming language, competing with the likes of JVM/NET/Go/Ruby. This focus is likely Crystal's main edge. The only other single-executable opinionated GCed language is Go. Crystal's type system is much better than Go's. If Crystal can reduce compile times and capture some of Go's pragmatic aura, it will see more success.

I disagree. Language does matter for long term maintenance. For instance with a tax rebate.

Static typing - a fancy language feature - can immediately tell you the function deals with money. +1 for maintenance. Static typing with a solid IDE will immediately reveal everywhere the function is used. +1.

Languages shepherd you into certain designs or mistakes by making some things easier than others, such as when class inheritance can be easily abused in OO languages, cryptic one liners are easy in Perl, point-free cleverness in Haskell, monkey patching in dynamic languages, etc. +/-1 depending.

Per documentation, languages come with tools and best practices: Javadoc, Godoc, Rustdoc; C# even has a dedicated comment syntax for documentation - a fancy language feature. +1. No one does documentation, until the language tooling forces them to.

That said, BG (Before Git) and widespread use of source control, as in '96 to '02, was a dark age. We know more now.

What about F#? Often seems underappreciated

I'd say the two big ones are:

- Mature support for async/await since 2012. Yes, Project Loom is coming, a decade later..

- Support for generic-aware value types (struct vs. class) and low-level features like stackalloc: very valuable for high-performance scenarios and native FFI. See for instance https://github.com/ixy-languages/ixy-languages. In comparison, Java doesn't even have unsigned integers. Yes, Project Valhalla is coming someday.

As well, debatable to some folks, but: properties (get/set); operator overloading; LINQ > Java streams; extension methods; default parameters; collection initializers; tuples; nullable reference types; a dozen smaller features

> You can barely tell the code bases are related beyond being functionally similar.

Not sure if you've missed this, but this is a number one reason many consider C++ absurdly complex. To actually know C++ is to know many different similar languages based on the year the code was written. C++20 is very different than C++03 as noted. Now compare this with C, or Go, Java, etc. which in comparison have barely changed.

We live in a world where not long ago smoking was considered fine by doctors. Where fat is demonized on nutrition labels while obesity surges. Where leaded gasoline was banned in gas not that long ago. Where a dozen diseases are increasingly prevalent and we have no idea why. To suggest that medicine hasn't figured something out is completely sensible. It can be argued that mRNA vaccine breakthroughs might not have happened without COVID, before that we didn't have it figured out. How many ophthalmologists are doing research, and how many are doing their job and going home because research doesn't pay? In every age many are convinced we've reached the pinnacle of science and have everything figured out, and that is pants on head retarded.

There's a great recent video from Real Engineering showing how Javelins work to annihilate tanks.

https://www.youtube.com/watch?v=SUdHzKRiBX8

> A JS engine can do this trivially

I'm not one to argue, computers are fast. However, this would be a huge paradigm shift for the JavaScript ecosystem, where compile-to-JavaScript-tools like TypeScript are dominant. These tools have explicit goals to do type checking at compile time only and avoid generating anything at runtime. Runtime checking is redundant in this paradigm.

Now if you're arguing that the JS engines like V8 should be able to use type information for performance gains, I understand that wish. WebAssembly seems to be taking over the performance angle these days though, as it was designed from the start for that purpose, unlike JavaScript.

> You're kidding right? .. will be stripped before a JS engine ever sees it?

Yes. We're talking JavaScript here - billions of lines of which are compiled every year to ES5 ;-; with polyfills. Throwing away hundreds of useful features of ES2016+. This is par for the course, part of the JavaScript paradigm which this proposal understands.

> sounds like a feature for your console

That is fair, though it seems unlikely Chrome would adopt such a feature for their console without motivation. Perhaps.

> Which enforced the types

Python does not enforce types at runtime? You might be referring to something I'm not familiar with. Fired up Python 3.9. This works fine even though I'm passing strings for int.

  def add(a: int, b: int):
      return a + b
  add("not ", "used") # 'not used'

> the cost of a mode switch is massive

But earlier you said a JS engine can do this trivially? I don't understand how this is now difficult. Ultimately, if the types are enforced, you may as well go the full monty and support TypeScript in the browser, with Deno leading the way. Stop beating the JavaScript horse and all. That's the dream. This proposal is a compromise without a doubt, with the understanding that TypeScript in the browser is politically untenable at this point.

> TS already does them?

TS runs the checks at compile time and compiles to JavaScript without annotations. There is no runtime cost.

> related page load perf impact

Type annotations would likely still be stripped by minifiers, just like comments. No change.

> burn the syntax

As a dev that regularly uses TypeScript, being able to use debug builds with annotations and copy paste TypeScript into the console would save a lot of time. This would be part of larger trend of adding type annotations to dynamic languages. Python, Ruby, and other dynamic languages have blazed the trail here. There are ways to add enforcement in the future if needed, just look at 'use strict';