Ich stimme dem Inhalt des Artikels nicht unbedingt zu, daher habe ich die Aussagen des Autors nur kurz wiedergegeben.
Im Ausland stimme ich bis zu einem gewissen Grad zu, dass Rust eine gute Performance bietet und dass es leicht ist, Leute dafür einzustellen, aber …
(Ob es hierzulande wirklich so viele Rust-Entwickler gibt, ist fraglich …)
Für Startups ist weniger die Programmiersprache wichtig als vielmehr, welches Problem gelöst wird.
Ich denke, wichtig ist, mit den zur aktuellen Situation passenden Tools schnell ein solides MVP zu bauen.
Wenn jeder Tag hektisch ist, wirkt die Aussage, dass es drei Monate dauert, sich an die Sprache zu gewöhnen, etwas daneben.
Wenn man Rust neben dem Job drei Monate lang als Toy-Projekt lernt und danach gründet, dann OK.
„Ich denke, wichtig ist, das passende Tool für die aktuelle Situation zu nutzen und ein MVP wirklich schnell sauber zu bauen.“
Ich denke, dass Rust gerade wegen dieses „wirklich schnell sauber“ eine gute Wahl sein kann.
Das Sprachkonzept zielt darauf ab, dass schon beim erfolgreichen Kompilieren ein gewisses Qualitätsniveau erreicht wird (deshalb ist der Compiler ziemlich streng), und ich denke, dass das dabei helfen kann, zu verhindern, dass bei hastiger Entwicklung schlampiger Code entsteht.
Ach so, das Problem, das ich meinte, ist … Ist es möglich, mit Rust "schnell und richtig" voranzukommen, wenn man sich damit nicht gut auskennt?
Ich bin mir nicht sicher, ob es ein Werkzeug ist, das "zur aktuellen Situation" eines Startups passt.
Wenn man sich gerade in der Phase befindet, eine Demo zu bauen, braucht man vermutlich keine Qualität. Das gilt wohl auch, wenn man nicht vorhat, das Ganze langfristig zu warten. Wenn das aber nicht der Fall ist, scheint sie notwendig zu sein.
Ich habe keine Startup-Erfahrung und weiß es daher nicht genau, aber ich denke, dass oft die Strategie verwendet wird, erst einmal schnell zu entwickeln und dann fortlaufend Updates auszuliefern. Wenn man es immer wieder auf später verschiebt, rücken Qualität und Stabilität am Ende in weite Ferne.
Deshalb könnte Rust, das schon auf Compiler-Ebene vieles erzwingt, eher ein hilfreiches Werkzeug sein.
Dem stimme ich zu.
In einer Situation, in der selbst Bibliotheken fehlen, damit einen Service zu bauen??
Ich denke, das wird später einen enormen Überarbeitungsaufwand nach sich ziehen.
5 Kommentare
Ich stimme dem Inhalt des Artikels nicht unbedingt zu, daher habe ich die Aussagen des Autors nur kurz wiedergegeben.
Im Ausland stimme ich bis zu einem gewissen Grad zu, dass Rust eine gute Performance bietet und dass es leicht ist, Leute dafür einzustellen, aber …
(Ob es hierzulande wirklich so viele Rust-Entwickler gibt, ist fraglich …)
Für Startups ist weniger die Programmiersprache wichtig als vielmehr, welches Problem gelöst wird.
Ich denke, wichtig ist, mit den zur aktuellen Situation passenden Tools schnell ein solides MVP zu bauen.
Wenn jeder Tag hektisch ist, wirkt die Aussage, dass es drei Monate dauert, sich an die Sprache zu gewöhnen, etwas daneben.
Wenn man Rust neben dem Job drei Monate lang als Toy-Projekt lernt und danach gründet, dann OK.
https://news.ycombinator.com/item?id=31736703
Auch in den HN-Kommentaren zu diesem Artikel gibt es viele Kommentare mit einer ähnlichen Sichtweise wie meiner.
„Ich denke, wichtig ist, das passende Tool für die aktuelle Situation zu nutzen und ein MVP wirklich schnell sauber zu bauen.“
Ich denke, dass Rust gerade wegen dieses „wirklich schnell sauber“ eine gute Wahl sein kann.
Das Sprachkonzept zielt darauf ab, dass schon beim erfolgreichen Kompilieren ein gewisses Qualitätsniveau erreicht wird (deshalb ist der Compiler ziemlich streng), und ich denke, dass das dabei helfen kann, zu verhindern, dass bei hastiger Entwicklung schlampiger Code entsteht.
Ach so, das Problem, das ich meinte, ist … Ist es möglich, mit Rust "schnell und richtig" voranzukommen, wenn man sich damit nicht gut auskennt?
Ich bin mir nicht sicher, ob es ein Werkzeug ist, das "zur aktuellen Situation" eines Startups passt.
Wenn man sich gerade in der Phase befindet, eine Demo zu bauen, braucht man vermutlich keine Qualität. Das gilt wohl auch, wenn man nicht vorhat, das Ganze langfristig zu warten. Wenn das aber nicht der Fall ist, scheint sie notwendig zu sein.
Ich habe keine Startup-Erfahrung und weiß es daher nicht genau, aber ich denke, dass oft die Strategie verwendet wird, erst einmal schnell zu entwickeln und dann fortlaufend Updates auszuliefern. Wenn man es immer wieder auf später verschiebt, rücken Qualität und Stabilität am Ende in weite Ferne.
Deshalb könnte Rust, das schon auf Compiler-Ebene vieles erzwingt, eher ein hilfreiches Werkzeug sein.
Dem stimme ich zu.
In einer Situation, in der selbst Bibliotheken fehlen, damit einen Service zu bauen??
Ich denke, das wird später einen enormen Überarbeitungsaufwand nach sich ziehen.