JetBrains brengt gedistribueerde en lichtgewicht IDE Fleet uit

JetBrains heeft een nieuwe IDE uitgebracht waarin code zowel lokaal als remote kan worden geschreven. Fleet is een lichtgewicht editor die volgens het bedrijf bedoeld is voor ontwikkelaars die een allround-applicatie willen hebben.

De tool heet Fleet en is als preview te downloaden. JetBrains zegt dat de tool alle functies bevat die gebruikers van een IDE mogen verwachten, zoals syntax-highlighting en automatische code-aanvulling, maar ook debugging en refactoring. Ook heeft Fleet een geïntegreerde terminal, ondersteuning voor Git, en port forwarding. In de toekomst worden plugins beschikbaar. Volgens het bedrijf is de codebase volledig nieuw opgebouwd en bestaat Fleet daarom alleen als losstaande IDE in plaats van dat die geïntegreerd wordt in IntelliJ Idea. Fleet is te gebruiken op Windows, macOS en Linux.

Voorlopig kunnen ontwikkelaars met acht talen en formaten aan de gang in de editor. Java, JavaScript, Python, Go, Rust, en Kotlin worden ondersteund, samen met TypeScript en Json. In de toekomst worden ook html, php, C++ en C# ondersteund, al is het niet bekend op welke termijn dat gebeurt.

Volgens JetBrains is de tool zo opgebouwd dat die gedistribueerd gebruikt kan worden. Er is een architectuur voor zowel de front- als de backend, en gebruikers kunnen een workspace-server en een bestandssysteemserver opzetten. Daarmee kunnen gebruikers de IDE opzetten op hun eigen machine, maar de code ook vanaf een andere machine inladen. De laatste kan wel alleen via ssh op Linux-servers, al vallen vm's daar ook onder. Die remote-ontwikkeling wordt daarnaast ook doorgevoerd in alle tools van JetBrains' IntelliJ-platform.

Voor dat laatste heeft JetBrains Space uitgebracht. Dat is een platform waarmee ontwikkelaars kunnen werken vanuit een Docker-omgeving die bij JetBrains op de servers draait. Gebruikers kunnen daarin bijvoorbeeld Git-repo's klonen of indexes opzetten. Zulke containers kunnen wel met slechts één repository omgaan.

Reacties (91)

[jaenster]

Cool. Een van de grootste klachten bij IDEA is dat het relatief zwaar is. Verder, eenmaal jetbrains gewend en je wilt niks anders meer

[.je]

Ik ben anders best tevreden met VSCodium. Dit is een aparte compile t.o.v. VSCode, waarmee MS je oa tracked via telemetry.

Wat ook op het linkje hierboven word gezegd:

Microsoft’s vscode source code is open source (MIT-licensed), but the product available for download (Visual Studio Code) is licensed under this not-FLOSS license and contains telemetry/tracking.

Begint me overigens wel op te vallen dat je tegenwoordig behoorlijk wat verschillende soorten IDE's kunt vinden die allemaal een graantje mee proberen mee te pikken.

Gaat Fleet niet wederom aanvoelen als een "yet another IDE" ?

[Reactie gewijzigd door .je op 22 juli 2024 13:26]

[Martinspire]

Dit is een aparte compile t.o.v. VSCode, waarmee MS je oa tracked via telemetry.

Ja er wordt data verzameld, maar dat is product data, niet gebruikersdata of data van je project/code. Dus gebruik je feature x of y en waar moeten ze de ontwikkeling op focussen. Dit doet tegenwoordig bijna elk softwarepakket en online dienst wel. In principe is het niet anders dan pageviews om te kijken welk tweakers artikel populairder is.

[goldk]

With Fleet, we take that approach one step further by making it a single IDE. You no longer have to open different IDEs to get the functionality you need for your specific technology. With Fleet it is all there in a single application.

https://blog.jetbrains.com/blog/2021/11/29/welcome-to-fleet/

Wat ik opmerk aan het blogpost van JetBrains lijkt mij dit juist een alternatief voor all die IDE's en is dit niet een "Yet another IDE" maar juist competitie voor zoiets als Visual Studio Code. Ik ben wel benieuwd wat het prijsmodel gaat worden.

[Reactie gewijzigd door goldk op 22 juli 2024 13:26]

[YopY]

eh? IDEA Ultimate is ook al "one IDE to rule them all", en dat was van origine hun enige product, totdat ze bedachten dat ze ook taalspecifieke versies konden uitbrengen. Onder water is dat gewoon hun ene IDE met beperkingen op welke plugins geinstalleerd kunnen worden, natuurlijk.

[Caelorum]

[...] Onder water is dat gewoon hun ene IDE met beperkingen op welke plugins geinstalleerd kunnen worden, natuurlijk.

Dat is wel iets te simpel gedacht. Rider is bijv. de frontend van IDEA, maar de backend is resharper en daartussen hun kotlin lijmlaag. Complete delen van de UI van Rider worden geremote vanuit resharper. Daar zit meer werk in dan alleen wat plugins.

[goldk]

Zo ver ik weet is IDEA niet "one IDE to rule them all" zoals jij opmerkte, maar voornamelijk gericht op JVM gebaseerde talen zoals Java, Scala en Kotlin. Ja er zitten plugins bij voor web front-end's maar voor zaken zoals C# of C++ zou je toch Rider of CLion moeten pakken.

[DrPoncho]

Kwestie van tijd voordat er een editor uitkomt die YAI of YAIDE heet ja ..

[Homewrecker]

Zeer tevreden van VsCode maar voor Java dekt die toch de lading niet.

[FateTrap]

Wat is er beter aan VSCode en Fleet, tov van het minder zware en krachtigere Emacs?

[faxityy]

Beginner friendly, hedendaagse UI/UX.

[iApp]

Het doet me trouwens verrekt veel denken aan Sublime Text. Deze lichtgewicht IDE is in C++ geschreven en werkt daardoor super snel! Ik gebruik het zelfs als vervanger voor Kladblok.

[gimbal]

Daarom heet het ook Sublime Text en niet Sublime IDE, het is een (rijke) tekst editor. Verder geeft iets schrijven in C/C++ geen garantie dat het meteen supersnel is, dat hangt toch echt van de programmeur(s) af.

[n9iels]

Ik denk dat JetBrains zich wil gaan onderscheiden met dat het allemaal werkt binnen hun eco-systeem. Dat is wel een selling-point als je alles van JetBrains gebruikt. Maar het is en blijft inderdaad wel wederom "een nieuwe IDE".

[CH4OS]

Gaat Fleet niet wederom aanvoelen als een "yet another IDE" ?

Hoe is VSCodium voor jou dat momenteel niet dan?

[CH4OS]

Is ook wel omdat het geschreven is in Java.

[Cheap Apps]

Ik ben benieuwd naar je onderbouwing hiervoor, waarom maakt de taal Java applicaties zwaar?

[jaenster]

Omdat java een van de eerste groot schalige JIT talen is, is er een soort mythe onstaan dat het zwaar / log is. Terwijl het een stuk sneller is als bijvoorbeeld .net (de andere grote jit taal).

Het is een soort rare running gag geworden dat java traag is, php onveilig. Mensen praten elkaar na zonder ook maar iets er van te weten. Persoonlijk ben ik geen fan van java, maar niet door zijn snelheid

[fastedje]

Java is zeker niet traag met de hotspot JVM, waar bottlenecks naar ca 10.000 iteraties wordt geoptimaliseerd in machine code. Java is wel hongerig naar geheugen en duurt relatief lang om op te starten

[CH4OS]

Op Linux valt het nog wel mee, maar ook op Linux heeft PhpStorm bijvoorbeeld altijd even nodig om op te starten. Zo ook op Windows, nog voordat het project geladen wordt, bedoel ik dan. Het is redelijk een typisch Java dingetje. Dat het überhaupt nog onderbouwd moet worden vind ik dan wat vreemd, bij Java is het inherent dat het opstarten van de applicaties dan altijd even duren (ivm het initialiseren van de JVM).

[Reactie gewijzigd door CH4OS op 22 juli 2024 13:26]

[Cheap Apps]

Ik ben zelf Java ontwikkelaar en het initialiseren van de JVM herken ik eerlijk gezegd niet als bottleneck. Dat IDEA even nodig heeft om op te starten is vervelend (met name indexeren kan zwaar op een systeem liggen), maar dat is nog niet per se gerelateerd aan Java zelf, maar aan de applicatie.

[vgroenewold]

De JVM warmt altijd iets op lijkt me en optimaliseert aan de hand van code welke het meest uitgevoerd wordt (C1/C2), dat merk ik soms wel aan applicaties.

[GertMenkel]

De JVM is tegenwoordig behoorlijk snel opgewarmd. Waar ik op Windows echt direct effect zie met het opstarten van IntelliJ of enig ander product is de antivirus. Er worden heel snel heel veel kleine bestanden ingelezen, elk met zijn kleine beetje overhead van de minifilter driver van de AV engine, en je kunt de opstarttijd gewoon drie keer verkleinen door de source map uit te zonderen van antivirus. Ook de git-map die je in veel projecten ziet, heeft hierop een impact.

De aanpak van Jetbrains lijkt te zijn "we bereiden één keer alles voor, dan kunnen we daarna direct van start" en die van de concurrentie (VS Code) lijkt te zijn "we zoeken het onderweg wel uit, als de gebruiker maar snel een gekleurde GUI ziet". Voor beide aanpakken is wat te zeggen, maar als ik een paar uur ga programmeren heb ik niet zo'n probleem met die twee minuutjes wachten tot alle nodige caches zijn opgebouwd. Mooi moment om nog even koffie te halen.

[Tielenaar]

Relatief zwaar misschien, maar met een beetje stevige developer PC merk je daar helemaal niks van.

[RMX]

Niet mee eens. Heb een beest van een pc maar het is echt traag bij grote bestanden.

[Tielenaar]

Wat is jouw definitie van een groot bestand? Een script van 50.000 regels? Misschien opsplitsen ofzo?

Ik heb projecten met 200k files erin en alles linkt aan elkaar alsof het niets is.

[YopY]

Ik werk met Typescript bestanden van 2 schermen groot (~200 regels tops) en IDEA heeft regelmatig moeite om mij bij te houden.

Maar ook met PHP bestanden van 6000 regels, daar werkt het nog wel redelijk bij, maar er zit zeker een paar seconden tussen dat ik ophoud met typen en dat IDEA de syntax highlighting en fouten checkt. Maar dat is begrijpelijk.

[bzzzt]

Jouw code is misschien maar 2 schermen groot, maar voor de foutcontrole moet Idea natuurlijk ook al je framework libraries bijhouden.

[Tielenaar]

Typescript is inderdaad drama. Zelfs kleine bestandjes vindt 'ie al moeilijk. Maar dat lijkt me eerder een niet goed geoptimaliseerde parser, iets dat in de toekomst wellicht beter wordt.

Ik heb (gelukkig) zelden PHP files met zoveel regels, maar je kan over het algemeen vloeiend doorwerken als hij ondertussen de syntax highlighting gaat bijwerken.

[CH4OS]

Sowieso zijn 6000 regels code in een enkel PHP-bestand wel wat overdreven natuurlijk...

[Groax]

Ach ik heb ooit een bestaand project moeten update met waarvan 1 bestand 12k lines. Alles was copy pasta en het zag er verschikkelijk uit. Werkte wel tho.

[Saven]

Niet eens alleen bij grote bestanden. 't Is een ontzettend logge applicatie geschreven in Java. Dan loopt 't gewoon niet zo lekker als een native applicatie. Gewoon niet zo vloeiend.

Ik stoor me er wel aan, maar er is eigenlijk geen echte concurrent voor iets als PhpStorm. Dus dan doe je 't er maar mee Ben wel benieuwd naar de performance van deze nieuwe app.

[Reactie gewijzigd door Saven op 22 juli 2024 13:26]

[Wolfos]

Ik merk daar totaal niks van in Rider. Het openen van bestanden vanuit Unity is instant - iets dat in Visual Studio meerdere seconden duurt. Alleen het opstarten van de applicatie zelf is wat traag maar dat doe je ook niet zo vaak. Ook bij de popups van Resharper merk ik geen enkele vertraging.

Nou moet ik zeggen dat ik ook niet met grote bestanden werk. Bij 200 lijnen begin ik mezelf af te vragen of dat niet gesplitst moet worden.

[Reactie gewijzigd door Wolfos op 22 juli 2024 13:26]

[pyotr]

Aangezien Fleet multiplatform is en Jetbrains de drijvende kracht achter Kotlin is verwacht ik dat ook Fleet zal draaien op een Java VM.

Ik zie het voordeel niet van Fleet t.o.v. IntelliJ (dat we naar volle tevredenheid op het werk gebruiken); tegen de tijd dat je alle "benodigde" functionaliteit hebt toegevoegd (denk aan SQL client, ondersteuning voor React, OpenAPI, etc) zit je niet ver naast de huidige situatie. En waarom zou ik mijn IDE willen splitsen in een frontend en backend? Wordt lekker ontwikkelen in de trein dan, over 4G of het brakke NS WiFi...

[Cyb]

"bij grote bestanden" is best wel vaag omgeschreven. Heb je het over source files of data files? bij openen? bij compileren? bij executen?

Traagheid kan ook gemakkelijk worden veroorzaakt door de third party build tools en virusscanners. IDEA kan daarom soms ook een melding geven met de tip om bepaalde directories te excluden.
(Had zelf onder een nieuwe Windows installatie ook te maken met een bepaalde traagheid bij het builden, maar het blijkt dat bij het builden de HD's uit slaapstand worden gehaald, wat ik pas merkte toen ik mijn koptelefoon afdeed. Het uit slaapstand halen geeft een vertraging, ook al zit de source files er daar niet op. Weet nog niet of het door IDEA of door Gradle komt.)

Voor de rest heb ik niet echt last van traagheid, en gebruik het al jaren.

[Ed Vertijsment]

Ik merk vooral dat PyCharm (een van de JetBrains ide's) traag is als het venster groter wordt, lijkt een soort bug in het ui (framework) o.i.d.

[pietschiet]

Werk je toevallig op een Mac met Apple Silicon? Want dan kun je in de VM config een trucje toepassen om het vlotter te maken

[Ed Vertijsment]

nee, intel MacBook Pro

[pietschiet]

Ja ik denk eigenlijk dat het daar ook voor geldt hoor, aangezien het te maken heeft met de huidige incompatibiliteit van de JetBrains IDEs met Apple's Metal API voor 2D rendering.

Wat je kan doen is, ga naar Help > Edit Custom VM Options, dan volgende twee lijnen toevoegen:

-Dsun.java2d.opengl=true
-Dsun.java2d.opengl.fbobject=false

Meer info rond dit issue, vind je hier

Samengevat: er komt binnenkort een nieuwe runtime aan waarin Metal support verwerkt is. Je kunt die zelfs nu al testen, maar dat zou ik je afraden want hij is nog erg instabiel. Wanneer deze uitkomt, kunnen de bovenstaande VM options weer uit Voor mij werkt het alleszins een pak soepeler zo! (MacBook Pro 2021 M1 Max)

[Reactie gewijzigd door pietschiet op 22 juli 2024 13:26]

[cricque]

Tsja niet iedereen heeft dat. Ik geef les python en laat de studenten vrije keuze tussen pycharm of vscode. Pycharm krijgen ze een licentie van 1 jaar via school. Ik heb hun ook uitgelegd uiteraard dat er wel wat naar microsoft verzonden zal worden. Ik gebruik zelf liever vscode, maar pycharm heeft zeker wel een paar nuttige zaken, maar is gewoon trager. Zelfs op mijn laptop voor school (recent model van lenovo met amd 5xxxx en 16gb ram etc) vind ik gewoon dat het nog altijd merkbaar is ... Bij sommige studenten is pycharm bijvoorbeeld redelijk traag, ook datagrip en die hebben een laptop i5 2-3 jaar oud bijvoorbeeld. Maarja traag is relatief, als ik nu terugdenk aan 30 jaar geleden dan is het nog altijd snel . Natuurlijk als je eenmaal snel gewend bent, dan wil je niet meer terug

Nuja ieder zijn ding, maar voor mij hoeft een ide in de cloud niet. Het voordeel is wel je kan het niet kwijtgeraken als je nog geen commit hebt gedaan. Maar bedrijfs kritische applicaties ofzo zie ik daar nu niet echt in gemaakt worden

[Reactie gewijzigd door cricque op 22 juli 2024 13:26]

[Cyb]

PyCharm Community Edition is gewoon gratis. De PyCharm Professional Edition is wel betaald, maar daar hoef je eerste jaars 101 studenten niet mee te laten werken. Tevens heeft JetBrains ook een PyCharm Education Edition.

Echt zwaar is deze software niet, maar de Professional edition kan wel zwaarder zijn. Ook eventueel PyCharm excluden in je antivirus software.

[vgroenewold]

Ja precies, dat snap ik niet helemaal, beetje weggegooid geld. De community edition kan vrijwel alles wat je nodig hebt, zeker om les in te geven.

[Cyb]

En voor het onderwijs zijn alle JetBrains producten (inc. Professional Editions) ook volledig gratis. Die "1 jaar" kan steeds gratis verlengd worden, mits het individu voldoet aan de eisen.

[cricque]

Voor educatieve doeleinde krijg je dus gewoon gratis licenties, natuurlijk is dat niet helemaal nodig. Maar voor mij maakt iedereen zijn oefening in notepad of zelfs vi. Iedereen vrije keuze zeg ik altijd, zijn genoeg editors/ide's beschikbaar

[GertMenkel]

Huh, school betaalt voor licenties? Je kunt met een leerlingmailadres alle Jetbrains tools gewoon gratis krijgen. Als school voor licenties betaalt is dat echt weggegooid geld, helemaal omdat er ook gewoon een gratis versie is.

Ik vind PyCharm niet zo zwaar voor wat het voor je doet. Het doet dan ook veel meer dan VS Code, en de echte vraag is of je al die extra features nodig hebt. Jetbrains tools zijn te vergelijken met Visual Studio (Community danwel Professional), en minder met VS Code naar mijn mening. VS Code is eerder de concurrent van dingen als Atom (bestaat dat nog?) en Sublime.

Ik vind voor Python de type inference van PyCharm bijvoorbeeld echt stukken beter dan die van VS Code en als je met libraries gaat werken, gaat dat een hele hoop uitmaken. Ook is de integratie met tooling een stuk dichter dan die van VS code, waar je snel handmatig command lines in JSON-bestanden loopt in te vullen.

Ik merk ook dat de Jetbrains IDE's geheugen vreten als een malle, maar dat is op Windows in de praktijk geen probleem. Het is vooral het achterlopende memory management voor GUI's op Linux dat problemen oplevert (omdat het OS een stuk minder vaak aan applicaties vraagt geheugen op te schonen, caches te flushen en dat soort dingen in vergelijking met Windows). Het geheugengebruik schaalt niet helemaal lineair, naarmate je meer libraries gebruikt lijkt het wel per library minder te gebruiken, maar voor complexe code bases analyseert de tool echt álles (waar VS code soms een zetje nodig heeft om te realiseren dat je een bepaalde library wil gebruiken, bijvoorbeeld met een specifiekere import).

[cricque]

De school krijgt gewoon licenties die 1 jaar geldig zijn, dus elk jaat vernieuwen. Uiteraard is dit toekomstige klantenbinding. Er is niks met pycharm en voor de dingen die jij aanhaalde ook effectief beter. Net zoals een virtualenv aanmaken .. leg dat maar eens uit aan mensen die geen dos kennen. Maar voor mij persoonlijk heeft vs code een groot voordeel … ik meng dagelijks python, go, react, node. Ik weet dat je dit via een of andere tool van hun ook wel kunt., maar ik gebruik al vs code sinds de beta op linux. Geen java nodig dus. Wat je wel hebt uiteraard is de integratie met django, flask, pyramid etc. Maar hetis 2 totaal verschillende dingen vergelijken. Voor mij maakt het niet uit, ik kan desnoods wel me vi overweg.

[GertMenkel]

DOS lijkt me niet meer zo relevant tegenwoordig, maar de command line leren is geen overbodige luxe op de lange termijn. Als beginnende leerling is het niet per se nodig (alhoewel het wel goed is om daar op tijd mee te beginnen! Zelfs al is het powershell…).

Ik ben van mening dat als je je tooling niet kent als ontwikkelaar (dus niet weet hoe je stap voor stap van source naar distributie gaat), je als ontwikkelaar vroeg of laat tegen een muur zal lopen vanwege vage bugs en assumpties die niet waar worden gemaakt. Knopjes gebruiken om dependencies te beheren en dingetjes in elkaar te flansen is heel leuk, totdat je een error krijgt omdat je een systeemlibrary mist of je een ander configuratieprobleem op je systeem hebt. De hoeveelheid vragen die je op internet kan vinden van mensen die al jaren in het vak zitten maar blijkbaar nog nooit hebben geleerd hoe hun compiler/minifier/packager eigenlijk in elkaar zitten is echt deprimerend.

VirtualEnv's zijn gelukkig een vinkje dat je aanzet in je IDE (in elk geval bij Jetbrains, ik weet niet hoe VS Code en VS Community dat doen), als je mensen maar vertelt dat ze het moeten doen om van start te gaan, kan iedereen daarmee beginnen.

Als je diverse backendtalen mixt heb je inderdaad meer aan IntelliJ Ultimate (met de nodige talen via het pluginsysteem) dan aan losse IDE's zoals JB ze ontwikkelt. De tooling van ze is op zich goed in zowel backend- als frontend doen, maar als je complexe frameworks van verschillende talen gaat mixen wordt het soms een uitdaging omdat de IDE is toegespitst op één framework.

Voor het spul van Jetbrains heb je overigens geen Java nodig, er zit een speciale JRE in de installer net zoals er een browserengine in de VS Code installer zit.

Ik werk in mijn vrije tijd met Rustcode en daarvoor is de tooling in en ondersteuning door Clion inferieur aan die van VS Code met alle nodige plugins geïnstalleerd, dus het is niet alsof ik per se Jetbrains tot aan de hemel wil prijzen. Voor Python vind ik Pycharm echter de onverslagen winnaar. Voor Java is dat IntelliJ, voor C# is dat Visual Studio (NIET Code, bedankt voor de naamgeving Microsoft) en voor PHP zou ik eerder naar VS Code gaan dan maar PhpStorm. Voor puur frontend is VS Code de beste, maar voor full-stack zou ik weer richting Jetbrains kijken.

Je moet je tooling afstemmen op je gebruik, en in mijn ogen is die tooling voor beginners vaak het beste bij de commerciële partijen. VB6 is nog steeds ongeëvenaard in hoe snel het je aan het werk lam krijgen, en daar betaalde je destijds dan ook dik voor, in zowel geld als de onvoorkomelijke realisatie dat het eigenlijk echt een kuttaal is. Ik heb de nodige snelle programma's en scripts in (neo)vim geschreven en ik doe het nog steeds graag, maar als iemand begint met programmeren moet je ze een zetje geven.

Of je doet het zoals sommige universiteiten en begint met hexcode schrijven voor een arduino, dan assembly, dan C, dan Python en als laatste Java om te leren OO programmeren. Het ligt er maar net aan wat je het beste vindt als leermethode.

[janbaarda]

Voor Python gaat er niets boven Spyder IDE. Geschikt voor Mac, Windows en Linux. Het biedt alles wat ik van een IDE verwacht en is bovendien open source.

[vgroenewold]

Zo is alles gewoon persoonlijk, er is geen "beste".

[janbaarda]

Mee eens, als je aan een bepaalde IDE gewend bent is dat voor je gevoel al gauw de beste.
Hangt er ook vanaf wat je nodig hebt.

[cricque]

Nog nooit van gehoord, maar lijkt me niet slecht. Het ding is als je meerdere dingen gebruikt door een dag zoals ik ... python, go, node, react, html dan is vscode toch echt wel de tool. Maar leuk alternatief

[Avoran]

Probleem is alleen dat veel developers (waaronder ik) een laptop gebruiken zodat ze op werk en thuis kunnen werken. Ik zie wel meerwaarde in een pc/server op kantoor en een lichte laptop met de IDE erop.

[Tielenaar]

Er zijn ook stevige laptops hoor

Ik kan me voorstellen dat niet iedereen een ruim budget heeft, maar dat is toch eigenlijk wel een investering die je als developer of werkgever zou moeten doen. 16+GB RAM en een i7/ryzen minimaal.

[Avoran]

Dat heb ik op het moment ook. Een laptop van €1700 gekregen. Helaas maar 16gb ram. Voor een grote applicatie is zelfs dat aan de krappe kant. (als ik phpstan draai, bijvoorbeeld, gebruik ik al 5gb, plus nog 3gb voor phpstorm, is al de helft). Voor dat geld kun je volgens mij een heel mooie pc op locatie neerzetten.

[LOTG]

Ja, maar dit is meer zoals VSCode. Het is niet het zelfde, aangezien het compleet gestript is. Dus je mist waarschijnlijk alle features waar je juist JetBrains voor gebruikt.

[YopY]

En alle features waar je IDEA just NIET voor zou gebruiken, zoals een volledige database editor, Docker management, commandlines, etc; veel van die tools wil ik liever in een CLI of een gespecialiseerde applicatie doen.

[CH4OS]

Je wilt geen commandlines, maar liever in de CommandLine Interface?
Je snapt dat de commandline in de editor gewoon een schil is over de CLI heen?

[Reactie gewijzigd door CH4OS op 22 juli 2024 13:26]

[gimbal]

Ieder zijn ding, ik wissel liever zo min mogelijk tussen applicaties. Ik vind de shell integratie en ingebouwde database support juist onmisbaar.

[Martinspire]

Zwaar, log, onhandige onoverzichtelijke instellingen, traag met starten en verouderde interface.

Het ziet er naar uit dat ze geen zin hadden de bestaande applicatie aan te passen, maar gewoon opnieuw zijn begonnen. Ik geef ze geen ongelijk. Ik zal ook niet verbaasd zijn als over 3 jaar de oude applicatie wordt uitgefaseerd.

[xs4me]

Eens, al was ik daarmee al geholpen met JetBrains Webstorm. Maar als Java ontwikkelaar o.a. biedt dat geen oplossing. Dan is Fleet zo te zien de uitkomst. Goede ontwikkeling.

[FateTrap]

Eens Emacs gewend wou ik niks anders meer. Dus het zal verschillen van persoon tot persoon. Ik denk dat Emacs nog steeds beter aanpasbaar is dan VS Code en Fleet. Bovendien is Emacs ook minder zwaar dan Fleet en VS Code.

[cascer1]

Als je in jetbrains toolbox zegt dat hij shell scripts kan genereren dan kan je een soort lightweight editor van IDEA krijgen om files te editen. Simpelweg `idea file.txt`

[Frozendroid]

De tool heet Fleet en is als preview te downloaden.

Waar dan?

[DoubleDot]

Via de link die daar vlak na staat Toegegeven, beetje knullig verwerkt in het artikel

[Reactie gewijzigd door DoubleDot op 22 juli 2024 13:26]

[Frozendroid]

Maar het is niet te downloaden. Daarvoor moet je een invite krijgen.

[TheBoneJarmer]

Dit dus. Ik probeerde het ook al verleden week toen het nieuws bekend werd op Reddit en toen moest ik inloggen en mij vervolgens inschreven voor een early access review program zodat JetBrains jou kan contacteren met een link naar de effectieve download.

[YopY]

https://www.jetbrains.com/fleet als je even doorklikt op het gelinkte artikel.

[Siebsel]

Daar kan ik me alleen inschrijven, maar niets downloaden.

[CH4OS]

Zulke containers kunnen wel met slechts één repository omgaan.

Hier wordt het afgedaan als nadeel, maar je wilt ook helemaal niet meerdere repositories in 1 container hebben draaien! Dan ga je aan het concept van containers juist voorbij!

Je wilt juist zoveel mogelijk van elkaar gescheiden hebben (liefst op service niveau). Ook voorkom je daarmee security issues waarbij meerdere omgevingen bij elkaars data kunnen!

EDIT:
Toch even een verdere duiding; de ontwikkel omgeving wil je het liefste zoveel als mogelijk gelijk hebben als met de productie omgeving, een containerized omgeving vergemakkelijkt dit. Dit maakt dat je je geen zorgen hoeft te maken over of dat zaken wel gaan werken omdat het productie anders werkt; je hebt het in de ontwikkelomgeving dan ook op die manier. De code (van de repositories) wil je daarom ook zoveel als mogelijk gescheiden houden. Die wil je echter ook op de uiteindelijke productie omgeving gescheiden houden, je wilt immers ook niet dat je bij elkaars data kan komen.

Met het werken in Fleet (of welke IDE dan ook) ben je natuurrlijk altijd ook met maar 1 project tegelijkertijd bezig, dus wil je ook met enkel de juiste omgeving dan "verbonden" zijn. Het is dus volstrekt logisch dat de genoemde containers maar met 1 repository tegelijkertijd overweg kunnen.

[Reactie gewijzigd door CH4OS op 22 juli 2024 13:26]

[Oon]

Dat viel mij ook op inderdaad, dan ben je óf je versiebeheer aan het misbruiken óf je container. Maar als je ziet hoeveel images er zijn op de docker hub en op github waarbij er een volledige stack van database tot nginx binnen één container draait dan kan ik me goed voorstellen dat JetBrains dit uiteindelijk toch mogelijk gaat maken, want daar is helaas wel vraag naar.

[SillieWous]

Hoezo is een volledige stack in één container draaien per se misbruik maken van je container?

[bzzzt]

Misschien handig het er op te houden dat je software dan simpelweg niet modulair en/of schaalbaar in elkaar zit. Want als je database + frontend in 1 container moet draaien en je database load loopt uit de hand word je verplicht om ook je frontend op te schalen. Leuk voor je cloud rekening...

[Oon]

Containers zijn single purpose, het idee is dat je containers (zoals @bzzzt aangeeft) snel kan schalen, en het liefst op zo'n manier dat je dus ook meerdere kopieën van edge services (denk nginx) kan draaien over verschillende locaties.

Als je meer dan één server hebt draaien kun je daarvoor gebruik maken van Kubernetes of Docker Swarm (of tal van andere vergelijkbare oplossingen) die automatisch containers beheren voor iedere losse dienst die in je stack draait, maar het hele idee van containers is juist dat je kleine stukjes hebt die makkelijk schalen en dat wanneer één container plat gaat er gewoon een nieuwe gestart kan worden zonder dat je daar zelf handmatig in moet schakelen. Heb je alles van je database tot en met nginx in één container draaien dan kan dat niet, want dan is een kopie dus ook altijd een volledige kopie van de gehele stack die niet (zomaar) met een andere draaiende kopie kan praten.

[SillieWous]

Je gaat er dan van uit dat scalability het enige is waar containers goed voor zijn. Maar dat ben ik zeker niet met je eens. Een container is voor mij vaak tool om een enkele instantie onafhankelijk van de host omgeving te draaien.

Als voorbeeld, heb ik een aantal containers met verschillende linux distros omdat dependencies verschillen. Hiervan draai ik maar een enkele instantie die ik voor compilatie start.

[SPee]

Voor een productieomgeving is dat aan te raden.
Maar ga je voor een ontwikkelomgeving (bv) een ELK stack in losse containers draaien? Of is een enkele container met alles-in-een ook voldoende?

Aangezien er in docker hub of github geen onderscheid is tussen "deze container enkel voor ontwikkel gebruiken" zal je deze "vervuiling" blijven houden.

[Oon]

Juist in een ontwikkelomgeving is een stack met losse services handig, zodat je gemakkelijk delen kan herstarten of bijv. een andere versie ergens van uitproberen.
Dus ja, zeker voor alles gewoon losse containers, zo is het bedoeld en werkt het het beste. Je kan (zoals ik al eerder zei) Docker Stack of Kubernetes gebruiken om zo'n stack van services te beheren en dan kost het niet meer (vaak zelfs minder) moeite dan een enkele container beheren met allemaal verschillende rommel erin.

Docker Hub heb je hierbij niet nodig voor je opslag, want je kan 9/10 keer gewoon bestaande images gebruiken. Mocht je je stack in GitHub willen zetten dan heb je in het geval van Docker Swarm letterlijk alleen een docker-compose.yml nodig met daarin de services beschreven, en evt. een paar config files per service die je anders ook nodig had gehad. Dus vervuiling is het absoluut niet.

[SPee]

In mijn huidige project is de deployment code al verdeeld over meerdere repositories.
Puppet facts in 1, puppet code in een andere. En onze monoliet wordt langzaamaan opgeknipt, wat allemaal in een aparte repo komt. Dat maakt deze "IDE" geen bruikbare oplossing.

En ondanks de "wil je het liefst zoveel mogelijk ontwikkel en productie gelijk" is dit in veel gevallen niet het geval. Ook bij ons is dat heel anders (prod: puppet, ontw: scripts+dir, db: dedicated vs shared met een schema per developer).
Containers zouden dit veel makkelijker maken, maar helaas.. onze ontwikkel VM's hebben niet die mogelijkheid.

Dus die beperking zie ik als een groot nadeel. Deze tool zal niet goed aansluiten op mijn werkzaamheden.

[GertMenkel]

Containers zijn niet alleen voor het pushen van applicaties naar productie natuurlijk. Docker-containers (en hun concurrentie) die hiervoor gebruikt worden zijn slechts één van de vele manieren om containers te draaien.

LXC gebruikt ook containers, maar die zijn persistent. Snaps draaien in containers met eventueel toegang tot je bestandssysteem. Ik heb LXC gebruikt om bijvoorbeeld tooling die uitging van Ubuntu 12.04 te draaien op een modern systeem. Het alternatief was een virtual machine à la vagrant of virtualbox, doe mij dan liever een container!

Ik draai ook postgresql en mysql in containers omdat installatie en configuratie ruk is. De database heeft niks te maken met de applicatie die ik schrijf, als er maar een compatible server draait op het endpoint tijdens het debuggen vindt de applicatie het prima. Daar zit data in van minstens zo'n vijf of zes applicaties, maar dat maakt natuurlijk geen bal uit.

Jetbrains lijkt hier Docker te gebruiken om makkelijk en eenvoudig kopieën van een ontwikkelomgeving op te zetten. Alle dependencies en tooling die je installeert is met binnen de container gelimiteerd en de opslag lijkt persistent te zijn. Eigenlijk gebruiken ze Docker een beetje zoals men normaal LXC gebruikt, lijkt het me. Een. Prima toepassing van containers.

[n9iels]

Duidelijk dat JetBrains hiermee de concurrentie met Visual Studio Code aan wilt gaan. Ik ben wel benieuwd of dit ook een gratis IDE blijft of dat hier toch nog een prijskaartje aan komt te hangen. Daarnaast ben ik ook benieuwd hoe dit met WSL gaat samen werken, VSCode heeft daar nu ingebouwde ondersteuning voor.

[Reactie gewijzigd door n9iels op 22 juli 2024 13:26]

[Loller1]

Ik heb een licht blauw vermoeden dat Fleet gewoon Visual Studio Code is.

[Dare Devil]

Nope, is niet gebaseerd op Electron. Geschreven in Kotlin, met wat Rust voor native zaken.
Bron: https://twitter.com/en_Dal/status/1465248632949592073

[com2,1ghz]

Lightweight is een vreemde benaming hiervoor. Er zit een hoop functies in. Highlighting, GIT, terminal, remote. connecties. Dit is gewoon een volwaardige IDE die herschreven is.
Met lightweight denk ik eerder aan VSCode waar je met plugins de boel zelf kan inrichten.

[Creesch]

Highlighting, GIT, terminal,

Dit zit standaard echter ook in VSCode dus zo groot is het verschil niet als je nu doet lijken.

[HitDyl]

Als je VSCode volhangt met niet op elkaar afgestemde community plugins kan je juist weer beter voor een volwaardige IDE kiezen die is afgestemd op een specifieke doelgroep Webstorm, Rider, PyCharm etc. Dat is denk ik ook het idee hier met Fleet.

[e.dewaal]

Dat is ook mijn ervaring. Ik ben voor php van atom (github) afgekomen. Vervolgens naar VS code, maar dat werd net als atom erg traag. Project ingeladen in phpstorm en instellingen gemaakt. Geen problemen en runt als een raket.

[GeroldM]

VS Code die na een basis installatie al richting de 300 MByte gaat, zonder extensies. Dan denken jij en ik in heel verschillende termen als we het hebben over 'licht gewicht'. Vergelijk het met een Sublime of Notepad++ die rond de 30 MByte zijn, zonder extensies.

Tegen de tijd dat Notepad++ en/of Sublime net zoveel ruimte innemen (met extensies!) dan VS Code zonder extensies, dan lijken Notepad++ en/of Sublime al heel wat meer op een IDE dan dat VS Code dat doet.

Vandaar dat je heel veel van VS Code kunt zeggen of vinden, maar dat 'licht gewicht' een beetje te ver gezocht is. Dat wil dus niet zeggen dat het geen bruikbare editor is. Of niet ideaal voor jouw doen en laten, met of zonder extensies.

[GertMenkel]

Ik vind 300MB voor een IDE niet zo groot, eigenlijk. Sumbline en Notepad++ zijn geen IDE's maar tekstverwerkers met speciale foefjes. Voor veel dingen is dat ook exact wat je nodig hebt, bijvoorbeeld als je snel een scriptje in elkaar wilt zetten of als je andermans broncode door wilt scannen. De vergelijking met VS Code en vrienden vind ik alleen wat krom.

Ik zou Notepad++ en Sublime eerder vergelijken met (neo)vim en emacs, en dan zijn die laatste twee weer de lichtgewichten. Die 30MB is al snel overkill voor een tekstverwerker.

Eerlijk gezegd vind ik het allemaal wat overdreven om 300MB bloated te noemen in de tijd van 4K-schermen en laptops die standaard met minstens een kwart terabyte SSD-opslag komen.

Die 300MB is niks vergeleken met de caches en hard links daarnaar zodra je één keer een pip install of npm install draait om afhankelijkheden binnen te halen. Met een middelgroot project zit je al snel aan een halve tot een hele gigabyte per project, en dat wordt niet altijd gedeeld met de rest van je systeem (bijvoorbeeld als je Python virtualenvs gebruikt, zoals je tegenwoordig eigenlijk zou moeten als je Python programmeert). Hell, ik heb diverse projecten in Docker gepleurd waarbij ik erachter kwam dat je voor het installeren van bepaalde Python-dependencies een C, C++ én een Rust compiler nodig had, en hetzelfde geldt voor moderne Javascript. PHP en composer zijn nog lichtgewichten in vergelijking met wat je nodig hebt om moderne ontwikkeling te doen in de concurrentie.

[Chris_147]

Het remote werken lijkt me wel zeer interessant voor grotere organisaties!
1x project opzetten en iedereen kan het of een eenvoudige kopie gebruiken.

Is dat iets wat in de Visual Studio wereld ook al kan? (al enkele jaren niet meer echt serieus bezig geweest in VS)

[mdgf]

Met code wel ja (waar dit mee concurreert): https://code.visualstudio.com/docs/remote/remote-overview

[Reactie gewijzigd door mdgf op 22 juli 2024 13:26]

[ZakKa.dev]

Cool. Tevreden met vscode maar ga het zeker uitproberen.

[Crack_david]

Zou het remote development bij hun ook de manier worden hoe ze WSL goed gaan ondersteunen?