Live data from Hacker News

Why Rust is a great choice for startups

dailyedit.com

261–270 of 294 posts

Re: Why Rust is a great choice for startups

#261

Earlier quoted context omitted.

I've seen this in action: A startup I did consulting work for had a "genius" who convinced management that everything should be written in Haskell. As a consequence building a team was painfully slow, so slow that some guy in a weekend recreated in node.js what their 15 people team had painstaking put together in 3 months. Turns out doing a web service with tools meant for it was better than "everything should be fun…

I'd really love to hear more details about those Haskell services. I'd put money on either the team not knowing Haskell when they started, or the "genius" was one of those completely impractical people who do type-level astronautics in Haskell.

I think you just described the only two types of Haskell programmers that actually exist in a meaningful number.

Re: Why Rust is a great choice for startups

#262

Earlier quoted context omitted.

Unpopular opinion - Haskell was intended for research and learning, not so much for mainstream production code. I'm not saying you can't use Haskell for that purpose, but you should think long and hard before doing so. If the answer is still yes then go back and make sure you've thought long enough and hard enough! :)

Haskell is fine for production code. You just need to know what you're doing, and not go crazy with abstraction.

Haskell culture is all about exploration, which means you do not know what you are doing, by definition. A large part of that exploration revolves around abstraction.

Re: Why Rust is a great choice for startups

#264
post #75

Earlier quoted context omitted.

So, F# with NuGet/Fake, Scala or Kotlin with Maven/Gradle, OCaml with OPAM. Those points are hardly Rust specific and apply to any compiled language with ML influences.

From the official "Maven in 5 Minutes" tutorial: mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false From the official Rust lang book, Cargo section: cargo new my-project I guess it's a matter of taste...

I think it's worth making the distinction between Maven as a build tool and Maven as a package manager, because the latter I think does work quite well.

I've had enough maven for a lifetime. Too much time spent fiddling with settings.xml files and m2 folders, debugging builds in enterprise environments with dozen module projects and a mix of internal and public dependencies.

Re: Why Rust is a great choice for startups

#265

Earlier quoted context omitted.

The entire way of coding in Rust revolves around satisfying the borrow checker. At some point it may become second nature, but you are still jumping through Rust's hoops, which will make your code full of compromises that would otherwise not exist.

So does the entire way of coding in any static-typed language, your code is full of compromises that would otherwise not exist in a dynamic-type language. Rust is just another layer of static typing.

Yes. It's another level of the same problem.

Rust is like a piano where certain keys have been removed so you never play out of key.

Re: Why Rust is a great choice for startups

#266
post #252
post #161

Earlier quoted context omitted.

There are much more Scala devs than Rust devs.

Sounds like a bold claim to me, let alone the "much more" part. Have you got any data to support it ?

Well, it is hard to get a true picture without some probably paid data, but Scala has been around for longer (especially if we only look at the time when the language was reasonable well known), and I know plenty of companies that have significant Scala code bases even from the top of my head. Rust, not much. Of course I could be dead wrong, but I think as of now Rust has more hype than actual code written in it (but it is not baseless hype, imo the language actually lives up to it so its usage will likely grow faster than Scala’s)

Re: Why Rust is a great choice for startups

#267

Earlier quoted context omitted.

From the official "Maven in 5 Minutes" tutorial: mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false From the official Rust lang book, Cargo section: cargo new my-project I guess it's a matter of taste...

I think it's worth making the distinction between Maven as a build tool and Maven as a package manager, because the latter I think does work quite well. I've had enough maven for a lifetime. Too much time spent fiddling with settings.xml files and m2 folders, debugging builds in enterprise environments with dozen module projects and a mix of internal and public dependencies.

Now I guess you debug config.toml and build.rs files all the way up to ~/.cargo.

Re: Why Rust is a great choice for startups

#269

Earlier quoted context omitted.

FYI: If you're primarily IO-heavy, the GC pauses aren't going to be a big deal. Something like NodeJS (or Async .Net) will have great performance; even with garbage collection. (IO-heavy is the specific use case that NodeJS was designed to handle.) GC pauses really become a problem when you have long-lived objects in RAM. A generational GC (which pretty much all of them are) is designed to collect short-lived objects…

> FYI: If you're primarily IO-heavy, the GC pauses aren't going to be a big deal. Something like NodeJS (or Async .Net) will have great performance; even with garbage collection. (IO-heavy is the specific use case that NodeJS was designed to handle.) This just isn't true. Node is pretty terrible even at IO heavy workloads, especially if you have servers with many cores. Any benchmark will confirm this.

Not to be a pain but Node has its place in distributed, single-core servers

Re: Why Rust is a great choice for startups

#270
post #91

Earlier quoted context omitted.

Calling malloc isn't even manual memory management to me, it's just calling malloc. Writing malloc (not that hard in general! but tricky to get exactly the allocator performance or security properties you want for your use case) is manual memory management.

> In computer science, manual memory management refers to the usage of manual instructions by the programmer to identify and deallocate unused objects, or garbage. https://en.wikipedia.org/wiki/Manual_memory_management So, you can call it however you like, but calling `malloc()`/`free()` manually (emphasis on the `free()`, since allocation is explicit in most languages in form of `new` or something) is manual memory…

Why did you think this added to the conversation?
Post reply on HN