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

Migrating away from Rust

deadmoney.gg

Post reply on HN
Print view View original

691–700 of 799 posts

Re: Migrating away from Rust

#691

Post by acjohnson55 »

klabb3 wrote: post #655
acjohnson55 wrote: post #644

Earlier quoted context omitted.

I haven't tried Go in a while, but 8 years ago, I felt the tooling was a disaster. The V1 ways of doing things were really janky, and the improved versions didn't seem to be universally adopted yet. It's nice to hear that seems to have changed.

Yes, it used to be horrible with GOPATH hell, because Google didn’t care much about deps since they had their own monorepo. They got their shit together years ago. IMO today it’s better tooling than Rust (and Rust is pretty great already). Give it a try.

I love Crate, so if Go's tooling compares favorably to it, that's a good sign.

Re: Migrating away from Rust

#692

Post by elktown »

jerf wrote: post #677
elktown wrote: post #269

Earlier quoted context omitted.

This is goes for a lot of things in tech unfortunately. For example, being stuck in a SRE/devops amusement park can be incredibly frustrating and surprisingly resource intense. Sometimes it feels like we could use some kind of a temperance movement, because if one can just manage to walk the line one can often reap great rewards. But the incentives seem to be pointing in the opposite direction.

I'm beginning to develop a heuristic around the concept of "amount of the library you use". It's intrinsically fuzzy and still something I'm working on, but in general, it's bad to use only a tiny fraction of a library or framework, and really bad to have a code base in which a large number of things are pulled in that you only use small fractions of. There are some exceptions, e.g., pulling in your languages best-of…

That sounds like a good balance indeed.

Re: Migrating away from Rust

#693

Post by WalterBright »

chubot wrote: post #563
WalterBright wrote: post #470

Earlier quoted context omitted.

I caveat my remarks with although I've have studed the Rust specification, I have not written a line of Rust code. I was quite intrigued with the borrow checker, and set about learning about it. While D cannot be retrofitted with a borrow checker, it can be enhanced with it. A borrow checker has nothing tying it to the Rust syntax, so it should work. So I implemented a borrow checker for D, and it is enabled by addin…

So in D, is it now natural to mix borrow checking and garbage collection? I think some kind of "gradual memory management" is the holy grail, but like gradual typing, there are technical problems The issue is the boundary between the 2 styles/idioms -- e.g. between typed code and untyped code, you have either expensive runtime checks, or you have unsoundness --- So I wonder if these styles of D are more like separate…

> is it now natural to mix borrow checking and garbage collection?

D is as memory safe as Rust is, when you use the garbage collector to allocate/free memory. If you don't use the GC in D, then there's a risk from:

    * double frees
    * memory leaks
    * not pairing the allocation with free'ing
Those last 3 is what the borrow checker handles.

In other words, with D, there is no point to using the borrow checker if one is using D's GC for memory management.

You can mix and match using the GC or manual memory allocation however it makes sense for your program. It is normal for D programmers to use both.

Re: Migrating away from Rust

#694

Post by goku12 »

palata wrote: post #531
goku12 wrote: post #508

Earlier quoted context omitted.

There are 3 cases. The first is that you are comfortable with Rust and you just choose it for that. The second is that you're not comfortable with Rust and you choose something else that works for you. The third is the interesting one. When your service has a lot of traffic and every bit of inefficiency costs you money (node rents) and energy. Rust is an obvious improvement over the interpreted languages. There are a…

> Rust is an obvious improvement over the interpreted languages. Do we agree that most of the languages I mentioned above are not interpreted languages? You seem to only consider Go as a non-interpreted alternative...

I replied using my phone and couldn't see your original comment for reference. Yes, your list contains more compiled languages.

Of those, I'm not very comfortable with using C and C++ for backend development. Their lack of automated memory safety measures is an issue for services that are exposed to the internet. (To be clear, memory safety isn't the only type of safety required). Swift may be a fine choice. (I'm unfamiliar with it.)

JVM languages like Java, Kotlin and Scala are all compiled languages, but I'm unsure how well they satisfy what I said before. To repeat, what matters is energy efficiency and resource utilization (not speed). I hope that somebody can provide an insight into how much overhead they incur on account of running in a VM.

Re: Migrating away from Rust

#695

Post by WalterBright »

aapoalas wrote: post #657
WalterBright wrote: post #470

Earlier quoted context omitted.

I caveat my remarks with although I've have studed the Rust specification, I have not written a line of Rust code. I was quite intrigued with the borrow checker, and set about learning about it. While D cannot be retrofitted with a borrow checker, it can be enhanced with it. A borrow checker has nothing tying it to the Rust syntax, so it should work. So I implemented a borrow checker for D, and it is enabled by addin…

Hey, thank you for spreading the joy of the borrow checker beyond Rust; awesome stuff, sounds very interesting, challenging, and useful! One question that came to mind as a single-track-Rust-mind kind of person: in D generally or in your experience specifically, when you find that the borrow checker doesn't work for a data structure, what is the alternative memory management strategy that you choose usually? Is it ga…

Personally, I frankly do not need the borrow checker. I have been writing manual memory management code for so long I have simply internalized how to avoid having problems with it. I've been called arrogant for saying this, but it's true.

But I still like the borrow checker style of programming because it makes the code easier to understand.

I find it convenient in the D compiler implementation to use the GC for the AST memory management, as the algorithms that manipulate it are easier if they needn't concern themselves with memory management. A borrow checker approach doesn't fit it comfortably, either.

Many of the data structures persist to the end of the program, as a compiler is a batch program. No memory management strategy is even necessary for those.

Re: Migrating away from Rust

#696

Post by ryao »

pjmlp wrote: post #678
ryao wrote: post #665

Earlier quoted context omitted.

Yet the C++ community is continually trying to get people to stay away from anything involving C. That said, newer C headers using _Generic for example are not usable from C++.

Because C++ was "TypeScript for C", plenty of room to improvement that WG 14 refuses to act on for the last 50 years. Yes, most language features past the C89 subset are not supported, besides the C standard library, because C++ has much better alternatives, like why _Generic when templates are a much saner approach, than type dispatching with the pre-processor. However that is besides the point, 99% of C89 code minu…

C, unlike C++, does not really force new versions onto you, even if dependencies begin using them. That said, Linux switched to C11. Newer versions of C will gradually be adopted, despite the incompatibilities this causes for C++.

As for WG 14, they incorporated numerous C++isms into C. While you claim that they did not go far enough, I am sure you will find many who would say that they went too far.

Re: Migrating away from Rust

#697

Post by WalterBright »

WhereIsTheTruth wrote: post #615
WalterBright wrote: post #470

Earlier quoted context omitted.

I caveat my remarks with although I've have studed the Rust specification, I have not written a line of Rust code. I was quite intrigued with the borrow checker, and set about learning about it. While D cannot be retrofitted with a borrow checker, it can be enhanced with it. A borrow checker has nothing tying it to the Rust syntax, so it should work. So I implemented a borrow checker for D, and it is enabled by addin…

> I can also say confidently that the #1 method to combat memory safety errors is array bounds checking. The #2 method is guaranteed initialization of variables. The #3 is stop doing pointer arithmetic (use arrays and ref's instead). #4 safer union/enum, I do hope D gets tagged-union/pattern-matching sometimes in the future, I know about std.sumtype, but that's nowhere close to what Rust offer

Doing a sumtype is on the agenda and we'll get to it.

BTW, D has always had quite an advanced pattern matcher for types.

https://dlang.org/spec/expression.html#is_expression

https://dlang.org/spec/template.html#template_type_parameter...

Re: Migrating away from Rust

#698

Post by ryao »

gpderetta wrote: post #537
ryao wrote: post #380

Earlier quoted context omitted.

Try putting objects into two linked lists in C using sys/queue.h and in C++ using the STL. Try sorting the linked lists. You will find C outperforms C++. That is because C’s data structures are intrusive, such that you do not have external nodes pointing to the objects to cause an extra random memory access. The C++ STL requires an externally allocated node that points to the object in at least one of the data struct…

Unfortunately Stepanov and the STL are widely misunderstood. Stepanov core contributions is the set of concepts underlying the STL and the iterator model for generic programming. The set of algorithms and datastructures in the STL was only supposed to be a beginning, was never supposed to be a finished collection. Unfortunately many, if not most treat it that way. But if you look beyond, you can find a whole world th…

I have met a number of people who will not use the boost libraries. It has been so long that I have long forgotten their reasons. My guess is that it had to do with binary compatibility issues.

Re: Migrating away from Rust

#699

Post by bob1029 »

imtringued wrote: post #679
bunderbunder wrote: post #148

Earlier quoted context omitted.

I worked in a regulated space at one time, and my understanding is that this is a big reason they chose .NET over Java. Java relies a lot more on third-party libraries, which makes getting things certified harder. Log4shell was a good example of a relative strength of .NET in this area. If a comparable bug had happened in .NET's standard logging tooling, we likely would have seen all of the first-party .NET framework…

None of this makes any sense. There is no waiting. You just do it. In no universe can you justify using a vulnerable log4j version. You force gradle to use the patched log4j and be done with it. Five years has nothing to do with Java. It means nobody cares about security in the first place. Outsourcing such a trivial security problem to Microsoft is just another nail in the coffin. "I have no capacity to develop secu…

> There is no waiting. You just do it. In no universe can you justify using a vulnerable log4j version.

I agree.

We had been doing interop with a Java process from C# to access some document processing functionality during the log4j incident. The library we were using depended on log4j and had a clear resolution at the time, but there was a big perception problem in our client base (i.e., non-technical people that we must suffer in order to continue doing business).

Our solution to the resulting paranoia was to remove Java from our stack altogether. It was a big pain in the ass to find an alternative, but it was definitely worth it from a customer service perspective. Our clients were very happy with this approach and it saved us from a lot of messy meetings that other vendors were sucked into.

Re: Migrating away from Rust

#700

Post by ChadNauseam »

ninkendo wrote: post #435
ChadNauseam wrote: post #99

Earlier quoted context omitted.

I wish more languages would lean into having a really permissive compiler that emits a lot of warnings. I have CI so I'm never going to actually merge anything that makes warnings. But when testing, just let me do whatever I want! GHC has an -fdefer-type-errors option that lets you compile and run this code: a :: Int a = 'a' main = print "b" Which obviously doesn't typecheck since 'a' is not an Int, but will run just…

> I wish more languages would lean into having a really permissive compiler that emits a lot of warnings. I have CI so I'm never going to actually merge anything that makes warnings. But when testing, just let me do whatever I want! I’d go even further and say I wish my whole development stack had a switch I can use to say “I’m not done iterating on this idea yet, cool it with the warnings.” Unused imports, I’m looki…

On the other hand, I can't count how many times I've written some code like

    let iteration_1_id = 10;
    dostuff(iteration_1_id);
    let iteration_2_id = 11; // warning, unused variable!!
    dostuff(iteration_1_id);
and then spent 10 minutes debugging why iteration_2 wasn't working, when it would have been resolved instantly if I had paid attention to the warnings.
Post reply on HN