Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 1.2

nim-lang.org

Post reply on HN
Print view View original

121–130 of 130 posts

Re: Nim 1.2

#121

Post by timClicks »

klohto wrote: post #117
DeathArrow wrote: post #108

Nim might be great. But how can a great language get traction if nobody big is behind it? Java and Python are being pushed by Silicon Valley and universities, Go is being pushed by Google, Kotlin is being pushed by Google, C# is backed by Microsoft and some big companies. Who can help Nim, or Crystal, or Rust or other new language? I look at many of them from time to time, see interesting developments, see exciting t…

Rust is being adopted by Apple so I wouldn’t worry about it.

And quite a few other big names, incl. Google, Amazon, Microsoft, Dropbox, ...

Re: Nim 1.2

#122

Post by SaxonRobber »

yjftsjthsd-h wrote: post #93
qqssccfftt wrote: post #92

Earlier quoted context omitted.

What if I care specficially not to add a dark mode?

Why exactly would caring about users lead you to omit something that makes things nicer for them?

Maybe the same reason why others choose to omit light modes, despite that being my preference.

Re: Nim 1.2

#123

Post by beagle3 »

MaxBarraclough wrote: post #116
rayman22201 wrote: post #114

Earlier quoted context omitted.

Did you see the parent comments about the new -gc:arc? It's suitable for hard real time. https://www.youtube.com/watch?v=yA32Wxl59wo

> Reference cycles cause memory leaks, beware. It isn't acceptable to just permit memory-leaks in case of cycles. There's no way we'd ever see something like that in a serious JVM. Unless there's some serious machinery to provide assurances against reference cycles, of course. Which sounds like an interesting research project, come to think of it.

> It isn't acceptable to just permit memory-leaks in case of cycles.

That's only in the new --gc:arc which is still somewhat experimental. The old gc, --gc:markandsweep IIRC, does detect cycles, and has a deadline schedule (i.e. you can tell it "I now have 5ms, collect as much as you can"); But it has per-thread heaps, which means passing data between threads often entails a copy. You also have --gc:boehm (no cycles, shared heap), and --gc:none (no gc, you should take care of freeing memory yourself).

Re: Nim 1.2

#124

Post by cmcaine »

timClicks wrote: post #121
klohto wrote: post #117

Earlier quoted context omitted.

Rust is being adopted by Apple so I wouldn’t worry about it.

And quite a few other big names, incl. Google, Amazon, Microsoft, Dropbox, ...

... and Mozilla. The company that most of the core team are from ;)

Re: Nim 1.2

#125

Post by matdehaast »

moonduster wrote: post #111
DeathArrow wrote: post #108

Nim might be great. But how can a great language get traction if nobody big is behind it? Java and Python are being pushed by Silicon Valley and universities, Go is being pushed by Google, Kotlin is being pushed by Google, C# is backed by Microsoft and some big companies. Who can help Nim, or Crystal, or Rust or other new language? I look at many of them from time to time, see interesting developments, see exciting t…

Surprisingly, a lot of large companies use Rust in-house. I work at Nando's, one of our biggest systems is in Rust, and we're a chicken restaurant business, so it's not just limited to bleeding-edge SV companies. Hoping we can open-source some of this stuff in the near future too to kind of show the world that Rust is ready.

Thats awesome to hear! Would love to learn more. I assume you are part of the South Africa Nando's group...

Re: Nim 1.2

#126

Post by winter_blue »

ptx wrote: post #109
winter_blue wrote: post #103

Earlier quoted context omitted.

I'm not sure why so many people describe JVM based software as "heavy"? Is it possible to describe what "heavy" here means in more scientific terms? Does it mean that startup is slow (possibly due to AOT)? Does it mean that consumes a lot more memory than the equivalent C/C++/JS/Python/etc program? (I don't think so.) Does it mean that code execution is too slow? (This hasn't been true for over a decade or close to t…

In an unrelated thread, someone posted this quote from the Mithril documentation on the differences from React, which sums it up pretty well: https://news.ycombinator.com/item?id=22777320 Java and React are fast by bringing a lot of sophisticated (heavy!) machinery. Nim and Mithril are fast by being small and simple. For example, the JIT makes Java fast – eventually. But initially it's interpreted and slow, with the…

The solution to that is to cache/save a pre-compiled binary on disk/persistent storage. This is what modern Android does.

You would just essentially need an installation step, where you compile the binary (maximally optimized for the architecture that it's running on), and save that to disk. All of the problems you described disappear with that -- no startup/AOT delay nor any JIT compilation delays.

Pre-compiling stuff is a small price to pay for the benefit of better-optimized higher-performance execution.

Another thing: you could do memory safety and other static analyses and security checks during the pre-compile/install phase. There's a lot of benefits to that.

For e.g. if you are able to statically verify and guarantee (ie mathematically provably) that the code will not commit any memory violations, then you could optimize away many of the bounds and other related checks. These sorts of verification must be done on the machine that is actually executing the code, since you can't simply trust a third-party, and must yourself verify such assurances/claims.

Re: Nim 1.2

#127

Post by chris_j »

moonduster wrote: post #111
DeathArrow wrote: post #108

Nim might be great. But how can a great language get traction if nobody big is behind it? Java and Python are being pushed by Silicon Valley and universities, Go is being pushed by Google, Kotlin is being pushed by Google, C# is backed by Microsoft and some big companies. Who can help Nim, or Crystal, or Rust or other new language? I look at many of them from time to time, see interesting developments, see exciting t…

Surprisingly, a lot of large companies use Rust in-house. I work at Nando's, one of our biggest systems is in Rust, and we're a chicken restaurant business, so it's not just limited to bleeding-edge SV companies. Hoping we can open-source some of this stuff in the near future too to kind of show the world that Rust is ready.

Please tell us more - I'd be really interested to hear what system it is and to learn about your experiences.

Re: Nim 1.2

#128

Post by nimmer »

DeathArrow wrote: post #108

Nim might be great. But how can a great language get traction if nobody big is behind it? Java and Python are being pushed by Silicon Valley and universities, Go is being pushed by Google, Kotlin is being pushed by Google, C# is backed by Microsoft and some big companies. Who can help Nim, or Crystal, or Rust or other new language? I look at many of them from time to time, see interesting developments, see exciting t…

> nobody big is behind it

Being a grassroot, community-driven project is a feature, not a bug.

Re: Nim 1.2

#129

Post by mikebelanger »

afiori wrote: post #80
mikebelanger wrote: post #59

Earlier quoted context omitted.

What do you mean by 'work for Google for free?' I don't see that being required anywhere on the site.

Probably it is a reference to the reCapcha hell Google may drop you into if you are deemed "suspicious"

ah ok. I never saw those captcha things as work per say, but yeah I guess they are. Free work for some model data somewhere.

Re: Nim 1.2

#130

Post by ptx »

winter_blue wrote: post #126
ptx wrote: post #109

Earlier quoted context omitted.

In an unrelated thread, someone posted this quote from the Mithril documentation on the differences from React, which sums it up pretty well: https://news.ycombinator.com/item?id=22777320 Java and React are fast by bringing a lot of sophisticated (heavy!) machinery. Nim and Mithril are fast by being small and simple. For example, the JIT makes Java fast – eventually. But initially it's interpreted and slow, with the…

The solution to that is to cache/save a pre-compiled binary on disk/persistent storage. This is what modern Android does. You would just essentially need an installation step, where you compile the binary (maximally optimized for the architecture that it's running on), and save that to disk. All of the problems you described disappear with that -- no startup/AOT delay nor any JIT compilation delays. Pre-compiling stu…

Sure, an AOT compiler for Java would solve some of these issues, at the cost of larger binaries and loss of the dynamic runtime optimizations that make Java fast for long-running programs (which is why Android uses a combination of AOT and JIT). Some people on this site often point out that expensive commercial AOT Java compilers have been around for a long time. JetBrains even used to provide an AOT-compiled binary of the Kotlin compiler for a while.

However, you were asking why people consider Java to be heavy. When people normally use or talk about Java, Java means a JRE derived from Sun's Java implementation. If you download Java to run the Kotlin compiler or IntelliJ, you're not downloading the Android runtime or some hypothetical AOT compiler - you're using something based on OpenJDK, which suffers from the heaviness I described.

Post reply on HN