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

Show HN: Rocket – Web Framework for Rust

rocket.rs

Post reply on HN
Print view View original

71–80 of 123 posts

Re: Show HN: Rocket – Web Framework for Rust

#71

Post by l1ambda »

strictfp wrote: post #59
jonaf wrote: post #56

Earlier quoted context omitted.

I've worked a lot with this pattern in Python (Flask), Java and Scala. I have found it a little inconvenient beyond the simple hello world app when dealing with Flask, but I haven't encountered this problem with Java/Scala. To date, I've worked on probably 4-5 separate applications using this pattern and it's worked quite well. I have also used Spring 4 on the JVM, which ... feels more flexible, but also has a lot of…

I've worked on everything you mention and more, and I find the simplicity of say node.js or SparkJava very refreshing when coming from metaprogramming frameworks. Once you go metaprogramming everything is suddenly metaprogramming. Data serialization is metaprogramming. Middleware is metaprogramming. Adding your own plugins to the framework becomes metaprogramming. Also, because the framework wants to create your clas…

Your post totally resonated with me, particularly how once you go metaprogramming everything is suddenly metaprogramming. I work at a Spring shop and we joke about how we should just be called Senior Java Annotators. I find it ironic that Spring does all this machinery in order to instantiate your application, yet often you end up needed to use the Order http://docs.spring.io/spring/docs/current/javadoc-api/org/sp... annotation anyway to get things to wire up in the right way...at which point, it is kind of like, what even is the point of using Spring then? We waste tons of time figuring out what is getting configured, injected, instantiated, etc. to the point where I'd rather just define everything myself in the order I need it, so I know exactly what I'm getting and why. I miss normal programming, normal debugging, and normal application initialization.

And then there is the problem of CGLib wrapping e.g. for @Transactional and other annotations. Of course, it only happens for other services calling into your wrapped service. If you call your own methods from within the service, you're hitting just the service instance, not the wrapped instance, which causes all sorts of headaches. Yet people still take this disaster further with Lombok/bytecode manipulation and aspects.

http://sparkjava.com/ looks very appealing; it looks very much like http://koajs.com/ which I really respect.

Re: Show HN: Rocket – Web Framework for Rust

#72

Post by jdright »

Cyph0n wrote: post #25
johnwheeler wrote: post #20

Earlier quoted context omitted.

I guess I'm contrasting Python with my Java experience so far as banging out prototypes quickly. In Java, I don't think the type system gets in the way so much as its classpath. It's been a long time since I've done Java, but you'd have to get your jars in order and write an ant or maven script to do the compile/run steps (or at least a bash script). I like that with Python I can just do pip install whatever and begi…

I believe Rust's package manager, Cargo, is quite similar to pip in functionality. I haven't used it myself, so I could be wrong.

It is way better than pip on the sense it works everytime. pip is not painless. It is close but miss by little. Got to hate it because of numpy.

Re: Show HN: Rocket – Web Framework for Rust

#74

Post by amelius »

aaron-lebo wrote: post #33
EugeneOZ wrote: post #16

Syntax is amazing! Hope (so much) to see it possible on beta soon. Maybe for somebody it's not a new thing, but for me this: struct Message { contents: String, } #[put("/ ", data = " ")] fn update(id: ID, message: JSON ) where message is auto-decoded - it's awesome!

Edit: should preface this by saying the framework looks really impressive. I've been looking for a Rust web framework to settle on and this is the most appealing. It's funny to note how much something small like this matters. It's syntax sugar and presentation, but the difference a comment like this has at the top of an HN post vs an ambiguous but detailed discussion about feature x...massive in effect. It doesn't se…

Personally I don't like domain-specific sugared syntax. I prefer clarity above all, especially since I hope to spend the least possible amount of time in the networking domain, and this means I'd otherwise have to relearn the syntax whenever I have to dig into the code again.

Re: Show HN: Rocket – Web Framework for Rust

#75

Post by oxymoron »

strictfp wrote: post #64
jonaf wrote: post #63

Earlier quoted context omitted.

Thanks for clarifying. I agree with you, mostly. This is exactly the reason why I refuse to use Lombok. It literally mutates your bytecode! That's a disaster waiting to happen, and a potential debugging nightmare. I think that there is a fair balance where metaprogramming has great utility. For example, I'm a huge proponent of Guice. And yes, sometimes it makes debugging issues a little more complicated. OTOH, withou…

Ok, I hear you. I agree somewhat, but not totally :) To me, the most important aspect of programming is to retain full control. I for instance want to be able to register my HTTP endpoints based on some data read from a file. I want to be able to start my app in server mode and run requests against it in any way I want during testing. What many of these frameworks do is to remove this power. Bytecode modification is…

To jump into a really interesting discussion: I totally get what the both of you are saying, but I think that the real problem are poor abstractions. In some sense SQL is code generation since it's a declarative way of describing what you want which the query planner figures out how to realize. At least to me, it's rarely a source of frustration. Why? Because it's a sound, proven abstraction based on a very solid foundation. In the frameworks that figure in this discussion, there's no such thing, and all the abstractions I've seen are leaky under some scenario.

That makes me prefer minimal, magic-free tools, because even if it's sometimes a source of extra effort, at least I won't have to spend time fighting the framework. The fear of boilerplate seems strange to me. I'd much rather spend the extra ten seconds of adding a route manually through a line of code than no time at all if it spares me having to spend an hour figuring out why my ContextProvider isn't being registered by the classpath scanner.

Re: Show HN: Rocket – Web Framework for Rust

#76

Post by iopq »

rubyfan wrote: post #68

I suppose this an advance for those already using Rust but the core message on the front page doesn't speak to me as a non-Rust person. FTA: Rocket is a web framework for Rust that makes it simple to write fast web applications without sacrificing flexibility or type safety . All with minimal code. I'm at a total loss for why I really care about this major part of their message (type safety). If I have already switch…

You can write a safe framework in Rust, or you could just have everything as Strings. Just because it's in Rust, doesn't mean you get safety from a lot of error conditions.

Re: Show HN: Rocket – Web Framework for Rust

#77

Post by stymaar »

Manishearth wrote: post #17
johnwheeler wrote: post #12

One of my influences, Armin Ronacher, has been doing a lot of Rust work lately, so I've been thinking about looking at it more closely since I appreciate his Python tastes. Is Rust simple and elegant in the sense that Python is? I've also heard it's for systems programming, which makes me think of C and has kept me away from it. I like how I can bang out scripts quickly in Python. Is the same true of Rust? edit: foun…

> I've also heard it's for systems programming, which makes me think of C and has kept me away from it. One of its major goals is making systems programming more accessible. So you shouldn't dismiss it because "systems programming = C", it's trying to change that! :) That's not to say it won't involve learning some systemsy concepts. But it won't be as scary as C. You can't necessarily bang out scripts quickly. A typ…

> We've often had feedback from Python/JS shops using Rust that learning Rust had the side effect of teaching them systems programming. I think that's pretty awesome.

I'm a self-taught developer who only practiced memory-safe languages before and I never dared trying C because of its reputation of being too difficult. Rust taught me a lot of things about system programming I never though I will learn one day.

A big thank you to the whole Rust team for that !

Re: Show HN: Rocket – Web Framework for Rust

#78

Post by sidlls »

I'm not sure the syntax extension specific items are good if the intent is to present this as an argument for moving to Rust from some other language for building such a framework. I'm a bit biased: I'd avoid using syntax extensions that aren't part of the standard, because it adds a point of friction for novice and seasoned Rust developers alike.

Re: Show HN: Rocket – Web Framework for Rust

#79

Post by ekidd »

rubyfan wrote: post #68

I suppose this an advance for those already using Rust but the core message on the front page doesn't speak to me as a non-Rust person. FTA: Rocket is a web framework for Rust that makes it simple to write fast web applications without sacrificing flexibility or type safety . All with minimal code. I'm at a total loss for why I really care about this major part of their message (type safety). If I have already switch…

> I'm at a total loss for why I really care about this major part of their message (type safety).

Honestly, you might not care about type safety. It depends a lot on the kinds of programs you write.

In general, a language with a good type system[1] brings several major advantages to the table:

1. If your program compiles, there's typically a 90% chance it will work correctly on the first try, even if you just changed hundreds of lines of code.

2. Big refactorings are much less stressful.

3. Emacs or Visual Studio Code (for example) can provide pop-up completions of names and methods.

4. Problems like mysterious nulls or data races can be prevented almost entirely at compile time.

One big downside is that it gets harder to do certain kinds of (runtime) metaprogramming and you need to use macros to get similar effects.

At this point, having worked professionally with Rust, I would recommend Rust to people who are really enthusiastic about the above benefits. But if you look at that list and say, "Meh, not worth it," then you might not want to adopt a younger language like Rust. Well, unless you need to get reasonably close to the metal without sacrificing safety, which is where Rust really shines. I just wrote a fast CSV sanitizer in Rust for processing gigabytes of input, and the compiler caught a subtle memory error when one CSV line spanned two buffer reads.

[1] For the sake of argument, a "good" type system in this context includes the ability to define custom collections with type parameters, it only allows NULL to appear where explicitly permitted, and it supports tagged unions with a nice "match" construct. This seems to be roughly the minimum feature set to get the full effect described above. Examples include Haskell, Elm, Rust, ML and (to a surprising extent) TypeScript.

Re: Show HN: Rocket – Web Framework for Rust

#80

Post by iopq »

amelius wrote: post #74
aaron-lebo wrote: post #33

Earlier quoted context omitted.

Edit: should preface this by saying the framework looks really impressive. I've been looking for a Rust web framework to settle on and this is the most appealing. It's funny to note how much something small like this matters. It's syntax sugar and presentation, but the difference a comment like this has at the top of an HN post vs an ambiguous but detailed discussion about feature x...massive in effect. It doesn't se…

Personally I don't like domain-specific sugared syntax. I prefer clarity above all, especially since I hope to spend the least possible amount of time in the networking domain, and this means I'd otherwise have to relearn the syntax whenever I have to dig into the code again.

When digging into new projects I always find that there's going to be cognitive overhead because of certain abstractions.

    let always_forward = Route::ranked(1, Get, "/", forward);
this is a normal function call, but what does it mean? Is that really better than special syntax that desugars to this code?
Post reply on HN