Hacker News new | past | comments | ask | show | jobs | submit | JTenerife's comments login

"Therefore, rather than making you spend lots of time trying to reproduce the exact circumstances under which a runtime concurrency bug occurs, incorrect code will refuse to compile and present an error explaining the problem. As a result, you can fix your code while you’re working on it rather than potentially after it has been shipped to production. We’ve nicknamed this aspect of Rust fearless concurrency. Fearless concurrency allows you to write code that is free of subtle bugs and is easy to refactor without introducing new bugs."

https://doc.rust-lang.org/1.30.0/book/second-edition/ch16-00...

These sound like quite bold claims to me.


Previous sentence in this paragraph:

> By leveraging ownership and type checking, __many__ concurrency errors are compile-time errors in Rust rather than runtime errors.


I'm pretty sure the OP meant that concurrency introduces many subtle bugs that are not related to memory safety and so cannot be prevented by the Rust compiler hence fearless is a bold claim.


No benchmarks or any other numbers. I wonder how much faster some typical Go code (some CLIs, Hugo or webservices) will run? Around 1%, 5% or 10%?

The Go compiler doesn't need to be smarter for Go's usecase. If it can be made smarter, fine. For best possible performance look at C/C++ or Rust.


"No benchmarks or any other numbers."

And yet plenty of logical argument. The author assumes a level of optimization experience on the part of the reader, for example that the reader appreciates the physical cost of branch mispredictions.


It's too bad Go has poor performance calling C functions, if it didn't I think most issues with the language could be worked around.


What issues are there with the privacy policies? Did I miss something?


The founder has some controversial views on how to develop the product, this includes more cloud integration.

https://old.reddit.com/r/git/comments/59j0yq/gitkraken_is_no...

On top of that GitKraken is closed-source and in the past there were concerns on telemetry collection: https://old.reddit.com/r/git/comments/4dgpgd/gitkraken_data_...

Nothing major, which is why I am still using it, but definitely enough to make you wary.


You could apply for a free license for open source.

https://www.jetbrains.com/go/buy/#discounts?billing=yearly


I unfortunately don’t qualify



You’re talking to someone who cringes at even paying for Netflix, let alone an IDE


Should your employer/clients do the same for you? :)


Does anyone know what's the status of Typescript support in Svelte is? This thread is understandably locked:

https://github.com/sveltejs/svelte/issues/1639

Still I'm curious.

Typescript and RxJS (or MobX) with Svelte as the afterthought (https://michel.codes/blogs/ui-as-an-afterthought) would be a nice combo.


I'm afraid Svelte with typescript will loose some of its charm. Typescript is a little more verbose and explicit, also it cannot be directly executed by the browser (so you need to compile it, yet it is intermingled with HTML at times — there's JSX for that but Svelte kinda wants to NOT go the JSX/ShadowDOM route)

Internally Svelte uses TS though, the author claims to love TS also! It just does not mix very well with Svelte.

Stencil.js and lit-element are better picks in this regard IIRC.


Pretty much as you can see. A lot of people want it. It's not done yet.

Obviously Svelte is a JS to JS transformative compiler - you need to make a TS to JS transformative compiler.

I'm hacking on my next app using TypeScript on the backend (particularly around the data layer) and JS/Svelte on the frontend. I would like TS on Svelte, but the rest of Svelte is compelling enough I'd still use it over older tech like React.


Yeah, I love the concepts, philosophy and the simplicity of Svelte, but sadly I can't consider using it until it has proper TS support.


Rust needs to settle down to reach broader adaption, because the ecosystem must stabelize. No business oriented project manager would choose Rust as an alterative to Go or Java while Rust has "only" a community http lib on version 0.12.

Sure, async needs to be shipped and polished, but then Rust needs to tell the world: "We have all you need and as stable as you need."


> Google's impact on the world is strongly positive.

I couldn't disagree more. Google doesn't make bazillions of dollars because they provide us with live traffic on maps. Google has significantly enabled and actively driven the mindless consume-everything-all-the-time culture with all the horrible consequences for our mental-health and the environment.

The world would be a much better place without the ones like Google, Facebook and Amazon.


As if the improvements of the dev tools weren't enough, they've created a sweet interactive tutorial (https://react-devtools-tutorial.now.sh)! Don't know it it's new, but I'am very impressed.


Where they=brianvaughn (I see he's also left a comment elsewhere on this post), who did most of the work on both the tutorial and the dev tools.


Glad the tutorial is helpful! :)

It was a last minute idea and I'm excited about how it turned out.


Agreed that this is trivial model.

Regarding React: In many webgl use-cases UI-framework overhead can be neglected as the user interacts either with the scene or the UI rendered by the framework. The browser doesn't usually need to update the DOM and the scene in one frame.


I think the question here is how well React Hooks and their reconciliation perform "at scale". What may not be a problem with a couple of 2D UI elements may turn into a disaster in a non-trivial 3D scene.


Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: