Earlier quoted context omitted.
Go belongs in the exact same bucket as Java and C#.
Ergonomically, yes. Logistically, no.
Why do you say logistically no? The challenges of distributing the runtime?
I love building a startup in Rust but wouldn't pick it again
171–180 of 496 posts
Re: I love building a startup in Rust but wouldn't pick it again
#172If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a…
NodeJS kind of muddies the waters. It ate a lot of use cases that would have previously been done in Java. That created conflict between backend teams that wanted statically typed code and a "boring" tech choice against "full stack" developers creating a backend service. I think Rust will see a lot of adoption in web services that are glorified CRUD APIs. It would have been a poor choice to do many of these workloads…
I've really tried to give js/ts in backend a go. Both by nodejs and deno. And by kickstarting my own projects as well as diving into experienced nodejs developers' code.
I really don't see how anyone choses nodejs/deno to anything.
Java imo gives you much less trouble, is more stable, has a working (!!!) Unit testing setup and exceptional runtime.
Next on my list is to give rust a go, since I'm intrigued by its features, but if I was to go fast I'd go with java any day.
Re: I love building a startup in Rust but wouldn't pick it again
#173Re: I love building a startup in Rust but wouldn't pick it again
#174Earlier quoted context omitted.
> It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes. What are you comparing it to? I believe parent meant that even if you clone everywhere, your code is still more likely to be faster than Node/Python, and potentially Go/C#/Java. One thing to note is that C++ code tends to allocate all over the place from copy assignment and constructors, and it's still very fast. Rust…
> your code is still more likely to be faster than Node/Python, and potentially Go/C#/Java Python very likely, Node probably too, not sure. I doubt it's true for the others. My guess is you're going to use less resources (memory etc.) but you're not going to beat their runtimes with hand-rolled GC (ref counting) and allocations all over the place.
Really depends on what you're doing.
The thing is if you know enough about why cloning is slow - like a really fat string or a tight loop - you probably also know enough to avoid that. At least in my experience.
There's a ton of rope in Rust with lifetimes, generics, etc. Most if not all generic bounds have implications about the user and caller. Choosing which type of methods you use to avoid allocation while prototyping can be exceptionally difficult to do and be correct.
Refcounting is not that bad imo, and is very very easy. The moment you're at "well we need to beat the performance of X" is probably when you can make better/intelligent decisions about how you allocate, whether to use Arena/Bump/etc.
Also, if you wanted to be in Go/C#/etc you just would. You're using Rust (in this discussion) because you wanted to. When performance is a concern, you can deal with it - but the basic allocation tricks (Arc/etc) don't represent such a significant performance loss that suddenly your Prototype no longer functions.
Re: I love building a startup in Rust but wouldn't pick it again
#175Re: I love building a startup in Rust but wouldn't pick it again
#176Earlier quoted context omitted.
Rust is a high development cost compared to node.js python or julia, but I'd say it is about the same as go or c#. Maybe a little better than all of those if you consider time getting test coverage. But if you are prototyping you probably aren't doing that. I'd say rust is a much lower development cost than c++ or java.
Golang absolutely has a faster development cycle than Rust. Unless you’re a Rust expert who never touches Go, but then it’s an issue of familiarity. Go devs hit the ground running and the ergonomics are streamlined, and the borrow checker and other rust restrictions don’t get in the way.
Given my downvotes you seem to be with the consensus on this one. I had 30 years of c++ development going into rust and I never found myself fighting the borrow checker. Golang seemed the same, just started coding and stuff worked mostly. But, the complexity of rust was familar coming from c++ with generics and macros but without some of the footguns, so it just seemed like power, not clutter.
I like go, but I wouldn't prototype in it, I'd pick julia or python. And if I'm familiar with the problem and want to code for production, rust really doesn't seem any slower to develop in than go to me and perhaps a bit less verbose. But in retrospect I think that is because of the direction I came at rust from means my habitual coding style lined up more closely with what rust expects. Its not a harder coding mindset, just a different one than someone who came from java would be used to.
Re: I love building a startup in Rust but wouldn't pick it again
#177Rust is a systems language, not a business language. If you're building an operating system or a software platform, to for it; the robustness will pay for itself in time to fix hard-to-find errors. But if you're iterating fast to find out what the program should be about to begin with, use a prototype-friendly language instead. With garbage collection.
I think if you've captured the essence of the discussion on the usability of Rust really well.
Re: I love building a startup in Rust but wouldn't pick it again
#178Since safety was the first reason given for using rust, I'll just point out: There are other safe languages. I think it's a really useful thing to have from day one, but it doesn't particularly point you to rust. Also, performance is really about learning what your bottle-necks are, profiling them and optimizing them. You probably have no idea what those are when you start, so it's not really the right time to try to…
Rust does a bit more on the safety front than typical programming languages.
Re: I love building a startup in Rust but wouldn't pick it again
#179Earlier quoted context omitted.
I prefer having extra work done writing code (adding "?") than having to do extra work reading code. Exceptions are functionally invisible control flow; it isn't clear to the reader that a function may blow up if the exceptions are unhandled.
Exceptions always work the same way. You learn how to read code with exceptions pretty quickly.
How does an explicit raise operator like '?' work any different than that? You can learn how to read it pretty quickly.
Re: I love building a startup in Rust but wouldn't pick it again
#180Earlier quoted context omitted.
While I think this is a good point, a lot of the answers cannot be determined by the generator of the exception. Your SQL library cannot know what the implications of an error are -- is this a minor part of the system for which the error can be logged but mostly ignored, or is it critical? Etc. People want error handling to vanish so that they can follow the "normal" flow, but in fact error handling is one of the cri…
This is sort of what HTTP codes get at though. The server doesn't know what you want to do with a 400 but it knows that the problem is with the request for example.
[deleted]